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ABSTRACT! 


Across  the  U.S.  Navy,  each  new  ship  class  implements  a  new  command  and  control  (C2) 
system  design,  leading  to  separate  design  and  development  efforts.  training  pipelines,  support 
requirements,  and  upgrade  activities.  This  project  serves  as  an  initial  step  in  determining 
whether  the  Navy  can  consolidate  C2  systems  by  defining  a  common  C2  system  architecture  and 
requirements  that  can  be  applied  across  all  surface  combatants  for  the  Surface  Warfare  and 
Maritime  Interception  Operations  missions.  The  project  applied  a  systems  engineering  process 
consisting  of  a  needs  analysis,  functional  analysis,  and  modeling  and  cost  analysis.  The  needs 
analysis  defined  key  user  objectives  and  needs  and  identified  threats  to  Navy  platforms.  The 
functional  analysis  included  the  core  tasks  of  requirements  definition  and  enterprise  architecture. 
The  modeling  and  cost  analysis  task  verified  the  C2  system  architecture  and  evaluated  possible 
training  course  hour  savings.  The  pro  ject  found  that  the  definition  of  a  common  set  of  C2  system 
requirements  and  system  architecture  is  feasible  and  docs  provide  possible  life  cycle  cost  savings 
to  the  Navy.  In  order  to  fully  evaluate  a  proposed  common  C2  system,  further  wort:  will  be 
required,  expanding  the  analysis  to  other  missions  and  assessing  the  cost  impacts  of  a  common 
C2  system 
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EXECUTIVE  SUMMARY 


The  Naval  Surface  Warfare  Center  (NSWC)  capstone  team  project  is  focused  on 
eliminating  redundancies  in  the  IJ.S.  Navy's  development  and  deployment  of  Command  and 
Control  <C2)  systems  across  multiple  platforms,  which  could  result  in  potential  cost  savings. 
Senior  leaders  across  the  Acquisition  community  acknowledged  deficiencies  of  acquisition  effort 
stemming  from  the  fact  that  various  ship  platforms  utilize  different  C2  systems  to  accomplish 
similar  ship  functions.  This  redundancy  results  in  potentially  unnecessary'  cost  to  maintain 
different  configurations,  training  curricula,  logistics  support,  and  upgrade  plans.  This  capstone 
project  develops  a  common  set  of  C2  functional  requirements  and  a  C2  enterprise  architecture 
applicable  to  Guided  Missile  Cruiser.  Destroyer  and  Frigate  class  platfomis. 

The  purpose  of  this  project  is  to  test  the  assertion  that  a  common  architecture  w  ill  result 
in  cost  savings  to  the  Navy,  and  also  to  demonstrate  a  methodology  to  develop  a  common 
architecture.  Acknow  ledging  that  development  of  a  complete  surface  combatant  C2  architecture 
is  a  complex  and  resource  intensive  task,  a  method  is  needed  to  bound  the  scope  of  the  problem 
for  the  capstone  project.  For  this  reason,  the  project  focuses  on  two  representative  mission 
threads  (surface  warfare  and  mantime  interception  operations)  to  bound  the  requirements  and 
architecture  development,  with  the  intent  that  the  same  processes  in  this  project  could  be  scaled 
to  other,  larger  applications. 

This  project  uses  a  tailored  system  engineering  process  based  upon  the  Defense 
Acquisition  University  systems  engineering  process  model  to  develop  a  common  architecture. 
The  systems  engineering  emphasis  is  organized  into  three  phases:  Needs  Analysis.  Functional 
Analysis,  and  Modeling  and  Simulation.  The  Needs  Analysis  phase  identifies  the  aspects  ofC2 
that  arc  of  greatest  concern  and  interest  to  the  U.S.  Navy.  These  include  supporting  the  entire 
surface  warfare  kill  chain,  positive  identification  of  contacts  utilizing  all  sensors,  integration  of 
off-board  sensors  into  the  tactical  picture,  supporting  automated  identification,  supporting 
distributed  weapons  control,  real-time  sensor  netting  and  preplanned  responses,  and  employing 
non-kinetie  and  non-damaging  effects.  Additionally,  a  threat  assessment  is  conducted  during  this 
phase  to  analyze  the  range  of  surface  threats  likely  to  be  presented  to  a  C2  system  during 
operations. 


xm 


Mission  system  functional  requirements  arc  developed  during  the  Functional  Analysis 
phase  based  on  information  contained  within  the  Navy  Tactical  Task  List.  Navy  Surface  Warfare 
ManuaL  various  Joint  Publications,  stakeholder  interviews,  and  also  derived  from  mission  thread 
analysis.  A  significant  aspect  of  the  requirements  effort  is  that  the  higher  level  joint  publications 
arc  used  to  tailor  the  requirements  to  the  mission  without  targeting  a  specific,  existing  C2 
system.  A  value  system  design  is  created  to  describe  the  objectives,  measures  of  effectiveness 
and  performance,  and  threshold  values  for  each  of  the  developed  requirements.  Architecture 
products  arc  developed  for  the  high-level  operational  concept  (OV-ll.  operational  activity  model 
(OV-5).  and  systems  functionality  description  (SV-4>. 

The  Modeling  and  Analysis  phase  is  used  to  validate  the  architecture  model  and  to 
examine  a  methodology  to  evaluate  potential  cost  savings  to  the  Navy.  The  simulation  capability 
of  CORE,  a  commercially  available  systems  engineering  and  design  software  tool,  and  Colored 
Petri  Nets  <CPN|  are  used  to  validate  the  consistency  and  execution  of  the  architecture.  The 
training  curricula  for  Aegis  and  Ship  Self  Defense  System  (SSDS)  arc  used  as  a  comparison 
study  to  validate  the  assumption  that  cost  savings  can  be  achieved  by  developing  a  common 
enterprise  architecture.  Common  training  courses  between  the  two  systems  and  the  hour* 
required  to  complete  the  training  for  each  system  are  mapped  to  the  functions  defined  in  the 
Functional  Analysis  to  ensure  that  the  training  covered  the  relevant  C2  functions.  Cost  savings 
in  the  form  of  man-hours  can  then  be  identified  in  areas  of  potential  training  redundancy. 

The  project  created  a  list  of  C2  system  requirements  and  a  validated  common  functional 
architecture  that  could  be  applied  across  multiple  platforms.  The  project  also  demonstrated  that 
a  common  system  architecture  could  result  in  reduced  training  costs  throughout  the  lifecycle  of 
the  system.  Thus,  the  report  recommends  that  the  Navy  acquisition  community  pursue 
opportunities  to  design  and  develop  common  system  architectures  as  cost  savings  initiatives. 
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I.  INTRODUCTION 


A.  PROBLEM  STATEMENT 

Surface  navy  ship  C2  systems  are  the  means  by  which  the  commander's  intent  is  made 
clear,  allowing  the  crew  to  know  what  is  required  to  meet  the  mission.  C2  systems  have  evolved 
from  19th  century  signal  Hags  to  modem  computerized  command  and  decision  systems 
| Edwards,  200X).  The  21st  century  US  Navy  defines  C2  as  'The  exercise  of  authority  and 
direction  by  a  properly  designated  commander  over  assigned  and  attached  forces  in  the 
accomplishment  of  the  mission.  C  ommand  and  control  functions  arc  performed  through  an 
arrangement  of  personnel,  equipment,  communications,  facilities,  and  procedures  employed  by  a 
commander  in  planning,  directing,  coordinating,  and  controlling  forces  and  operations  in  the 
accomplishment  of  the  mission”  (Office  of  the  Chief  of  Naval  Operations.  2007.  Glossary-!]. 
An  important  aspect  to  draw  from  this  definition  is  that  the  Command  and  Control  system 
includes  people,  hardware  and  software;  all  of  which  are  part  of.  or  support,  the  authority  and 
direction  process. 

Across  the  Surface  Navy  Enterprise,  each  new1  ship  class  implements  a  new  C2  design  for 
the  combat  system  with  a  unique  set  of  system  requirements  and  associated  architecture.  The 
U.S.  Navy  currently  develops  and  deploys  multiple  major  surface  C2  systems:  the  Aegis 
Command  and  Decision  system  on  Aegis  cruisers  and  destroyers,  the  Ship  Self  Defense  System 
on  aircraft  carriers  and  large  deck  amphibious  ships,  and  the  Total  Ship  Computing  Environment 
currently  planned  for  DDG-1000.  Each  of  these  unique  C2  systems  has  separate  design  and 
development  efforts,  training  pipelines,  support  requirements,  and  upgrade  activities.  Life  cycle 
costs  associated  with  maintaining  distinct  development,  test,  and  support  activities  for  each  C2 
system  are  very  high.  Capability  upgrades  to  these  systems  arc  costly  because  systems  arc 
complex,  tightly  coupled,  and  tied  to  specific  vendors  who  arc  protected  against  competition  by 
contractual  harriers  and  large  capital  requirements.  Upgrades  also  take  too  long  to  reach  the 
fleet,  possibly  being  obsolete  by  the  time  they  get  there  [Edwards.  2(M)X|.  System  operators  who 
arc  trained  and  experienced  in  one  C2  system  typically  arc  not  qualified  to  operate  the  others, 
which  limits  the  Navy’s  flexibility  in  manning  platfomis. 

To  address  these  problems,  the  surface  navy  acquisition  community  has  assumed  that 
there  is  potential  for  significant  cost  savings,  faster  introduction  of  war  fighting  capability,  and 
improvements  to  surface  fleet  readiness  if  a  common  set  of  core  C2  components  w  ere  developed 
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for  all  surface  combatants  [Benedict,  2008].  One  approach  to  achieve  a  core  set  of  C2 
components  is  to  define  a  common  C2  architecture  following  systems  engineering  principles. 

In  alignment  with  the  surface  navy’s  strategy,  this  capstone  project  focuses  on  the 
development  of  a  common  set  of  requirements  and  C’2  architecture,  to  support  two  specific 
mission  threads  for  implementation  on  multiple  surface  ship  platforms.  As  a  metric  for 
affordability,  the  project  will  evaluate  "school  house”  training  hours.  Specifically,  will  a 
common  C2  architecture  help  to  reduce  the  training  hours  required  for  the  operator? 

B.  PROJECT  DESCRIPTION 

In  an  effort  to  maximize  combat  effectiveness,  surface  combatant  platforms  use 
command  and  control  to  coordinate  employment  of  the  ship’s  sensors  and  weapons,  to  make 
sense  of  the  tactical  situation,  and  to  plan  and  coordinate  their  activities  with  those  of  other  units 
in  the  area  of  operations.  Department  of  Defense  Architecture  Framework  (DoDAF)  products 
provide  a  DoD-acccptcd  approach  for  describing  an  architecture  capable  of  performing  these  C2 
functions,  and  were  used  to  define  and  develop  an  enterprise-level  C2  architecture  that  is 
independent  of  existing  systems  or  platforms.  This  architecture  was  developed  to  support 
functionality  normally  performed  by  combatants  normally  assigned  surface  warfare  as  a  primary 
mission  area,  such  as  cruisers,  destroyers  and  frigates.  The  expectation  is  that  the  concepts  and 
processes  developed  in  this  project  are  scalable  to  broader  surface  platform  applications. 

The  DoDAF  products  are  based  upon  two  representative  mission  threads  and  associated 
C2  functionality.  Two  mission  threads  were  selected  for  this  project  to  capture  the  desires  and 
needs  of  the  stakeholder  and  to  scope  the  focus  of  the  project  into  manageable  overlapping 
areas.  The  mission  threads  assessed  were:  conduct  surface  warfare  (SUW)  operations  and 
conduct  maritime  interception  operations  (MIO).  The  selected  mission  threads  cover  both 
combat  and  non-conihat  conditions  and  represent  two  unique  roles  of  many  missions  that  a  C’2 
system  should  be  capable  of  performing  in  a  specified  area  of  operation.  The  conduct  SUW 
thread  includes  the  ability  of  the  C’2  system  to  process  and  assess  sensor  contacts,  track,  identify, 
and  report  possible  targets  as  well  as  support  engagement  decisions  while  maintaining  and 
supporting  the  Common  Tactical  Picture.  The  conduct  MIO  thread  includes  the  ability  of  the  C’2 
system  to  exchange  information  during  a  MIO  event  in  order  to  support  battlcspace  awareness 
and  decision-making.  In  short.  SUW  and  MIO  were  determined  to  be  broad  enough  yet  focused 
enough  to  represent  the  development  of  a  common  C2  architecture. 


A  set  of  cntcipnsc  C2  requirements  was  then  developed,  based  on  the  SLAV  and  MIO 
mission  threads.  The  common  set  of  C2  requirements  and  mission  threads  were  instrumental  in 
the  development  of  an  enterprise-level  C2  architecture.  Several  of  the  architecture  descriptions 
arc  presented  as  DoDAF  products.  Finally,  a  cost  analysis,  in  terms  of  training  hour*,  was 
performed  to  establish  avenues  in  which  the  IJS  Navy  may  realize  savings  by  using  a  common 
set  of  C2  requirements  and  architecture.  This  report  documents  the  methodology  and  the  process 
used  to  identify  the  superset  of  requirements,  providing  a  traceable  and  repeatable  means  for 
developing  other  C2  architectures  for  additional  mission  threads. 


C.  SYSTEMS  ENGINEERING  PROCESS 

A  tailored  system  engineering  process  illustrated  in  Figure  1  was  employed  to  establish 
the  C2  cntcipnsc  architecture  and  requirements.  This  process  is  an  adaptation  of  the  systems 
engineering  process  published  in  System  Engineering  Fundamentals  (Defense  Acquisition 
University,  2001). 


Needs  Analysis 


A  J  Stakeholder  Values  4  Metrics 
□  Threat  Parameters 


3  Representative  Mission  Threads 


□  C2  Requirements 

□  Enterprise  Architecture 

□  Metncs/Threshold  Values 


Figure  1:  NSW'C  Tailored  System  Engineering  Process 


The  Systems  Engineering  (St:)  process  model  for  this  project  consists  of  three  phases:  Needs 
Analysis.  Functxmal  Analysis,  and  Modeling  and  Analysis.  Each  successive  phase  builds  upon 
the  previous  phase. 
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The  tailored  process  consists  of  three  iterative  phases  which  began  with  the  Needs 
Analysis  phase.  This  phase  focused  on  research  to  understand  the  stakeholders*  needs  and 
expectations,  and  also  to  gain  more  insight  into  the  problem  statement.  This  phase  also  included 
investigation  of  the  two  mission  threads  and  threats  against  the  platforms.  These  mission  threads 
and  threats  were  analyzed  in  order  to  understand  the  operational  needs  and  objectives  of 
command  and  control.  The  mission  threads  also  provided  project  context  for  the  definition  of 
C2.  (For  example,  the  mission  threads  assumed  that  the  C2  system  included  human,  hardware, 
and  software  components.)  Stakeholder  Analysis  helped  to  identify  system  functionality. 
Mission  thread  definition  helped  identify  additional  functionality  and  provided  context  for  the 
system.  The  threat  assessment  provided  platform  threat  information.  The  information  gathered 
within  the  Needs  Analysis  phase  served  as  the  input  for  the  Functional  Analysis  phase  and  was 
used  as  the  basis  of  the  C2  architecture  and  requirements  development. 

In  the  Functional  Analysis  phase,  the  system-level  requirements  and  the  functional 
architecture  for  the  C2  aspects  of  the  platform  were  defined.  The  information  collected  in  the 
Needs  Analysis  phase  (c.g.  needs,  threats,  functionality)  was  documented  as  requirement  “shall*' 
statements.  These  written  requirements  represent  the  attributes  and  capabilities  that  the  C2 
system  must  possess  to  be  useful  and  meet  the  needs  of  the  stakeholders.  These  requirements  arc 
then  translated  into  functions  captured  in  the  functional  architecture  using  DoDAF.  Needs 
Analysis  was  then  re-evaluated  to  determine  if  further  stakeholder  input  was  needed  for 
clarification,  if  the  mission  threads  were  adequately  defined,  and  if  the  threats  were  fully 
established. 

The  Modeling  and  Analysis  phase  provided  simulation  and  model  verification  of 
functional  architecture  identified  during  the  Functional  Analysis  phase.  Analysis  was  conducted 
to  identify  methods  in  which  the  common  architecture  could  yield  potential  savings  in  the  areas 
of  training  and  capability  upgrades.  The  previous  phases  were  re-evaluated  to  determine  if  the 
requirements,  architecture,  mission  threads,  and  threats  were  adequately  developed.  The 
stakeholders  were  also  contacted  to  validate  the  progress  of  the  project. 

This  project  resulted  in  a  documented  process  for  developing  scalable  enterprise 
requirements  and  architectures,  as  well  as  specific  requirement  and  architecture  sets  to  support 
the  identified  project  mission  threads.  The  follow  ing  sections  more  clearly  define  the  phases  of 
the  process. 
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1. 


Needs  Analysis  Phase 


a.  Stakeholder  Analysis 

The  purpose  of  the  stakeholder  analysis  task  was  to  identify  the  stakeholders  for  the  ship 
(2  system  and  to  clieit  guidance  from  the  stakeholders  and  official  documents  to  identify 
direction  for  other  needs  analysis  tasks.  As  such,  the  stakeholder  analysis  did  not  produce  any  of 
the  major  end  products  of  the  project,  namely  the  architecture  and  the  C2  requirements,  but  it 
was  still  a  vital  step  in  the  process.  The  stakeholder  analysis  provided  foundational  information 
for  the  follow-on  tasks  that  ultimately  led  to  the  end-product  development. 

The  stakeholder  analysis  was  conducted  based  on  the  information  in  the  problem 
statement.  The  stakeholder  expectation  of  cunent  and  future  threats  was  used  in  the  threat 
assessment.  The  summary  of  naval  doctrine  was  used  to  enhance  the  mission  thread  definitions. 
The  stakeholder*'  desires  for  system  functionality  helped  define  the  architecture  throughout 
development.  The  stakeholders'  values  and  metrics  were  incorporated  into  the  value  system 
design.  Specific  stakeholder  needs  were  the  basis  for  the  requirements  definition.  The 
relationship  between  the  Stakeholder  Analysis  task  and  the  following  tasks  is  depicted  in  Figure 
7 


Problem 

Desired  Functionality 
Stakeholder  Needs 

Statement  Stakeholder 

Stakeholder  Values  &  Metrics 

Analysis 

Current  and 

Future  Threats  Threat  Threat  Parameters 

Assessment 

1 

Doctrine  Mission  Thread 

Representative 
Mission  Threads _ 

Definition 

Figure  2:  Stakeholder  Analysis  Task  Relationships 

The  finding  from  the  Stakeholder  Analysis  helped  suppiwt  Ihe  other  tasks  in  Need*  Analysis 
Phase,  and  also  provided  inputs  into  the  other  Phases  of  the  SI:  process. 
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The  stakeholder  analysis  began  by  identifying  the  key  stakeholder  organizations.  Then 
the  stakeholders  were  interviewed  and  a  range  of  stakeholder  documents  were  surveyed. 
Stakeholder  interviews  were  conducted  using  a  common  set  of  questions.  The  survey  of 
stakeholder  documents  ranged  from  high-level  maritime  policy  to  Naval  Warfare  Publications 
(NWP)  and  Naval  Tactics.  Techniques  and  Procedures  (NTTP).  These  documents  arc  listed  in 
the  stakeholder  analysis  section. 

b.  Threat  Assessment 

The  objective  of  the  threat  assessment  was  to  survey  current  and  future  threats  to  U.S. 
Navy  platforms  with  the  purpose  of  influencing  the  requirements  definition  task.  The  inputs  to 
the  threat  assessment  were  the  problem  statement  and  the  stakeholder  feedback  on  current  and 
future  threats.  The  primary  intent  of  the  threat  assessment  was  to  feed  the  threat  parameters  into 
the  requirements  definition  task.  The  threat  assessment  was  used  to  summarize  the  current  and 
future  threats  and  their  related  kinematic  characteristics.  The  threat  assessment  was  constrained 
to  an  unclassified  level.  Open  sources,  public  sites,  and  publicly  released  U.S.  government  and 
United  Nations  documents  arc  the  main  resources  for  threat  specifications.  Figure  3  summarizes 
the  relationship  of  the  Threat  Definition  task  to  other  tasks.  As  a  result  from  this  analysis,  threat 
parameters  were  established. 
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Figure  3:  Threat  Assessment  Task  Relationships 


The  Threat  Asscament  evaluated  threat*  that  \rere  identified  during  the  Stakeholder  Analysis. 
Threat  Parameter*  identified  during  thi*  process  were  used  to  supped  requirement*  development. 
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c.  Mission  Thread  Definition 


The  development  of  mission  threads  provided  a  means  of  scoping  and  bounding  the 
problem  to  a  manageable  level  that  would  help  identify  the  capabilities  and  limitations  of  the  C2 
Architecture.  The  threads  describe  representative  scenarios  in  which  the  ('2  system  is  expected 
to  perform,  and  provided  a  framework  for  the  functionality  of  the  C2  system.  Inputs  to  the 
mission  threads  came  front  the  outputs  of  the  stakeholders’  analysis  (such  as  summaries  of  Navy 
doctrine  and  publications)  and  were  used  to  develop  and  refine  the  mission  threads.  The  refined 
mission  threads  were  then  used  to  develop  C2  system  requirements  (the  requirements  were 
derived  from  the  mission  threads  to  meet  stakeholder  needs).  Figure  4  summarizes  the 
relationship  of  the  Mission  Thread  Definition  tasks  to  the  other  tasks.  As  a  result  of  this 
analysis,  representative  mission  threads  were  developed. 
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Figure  4:  .Mission  Thread  Definition  Task  Relationships 


Doctrine  identified  during  Stakeholder  Analysts  helped  define  context,  functionality  and 
relatxmxhip*  to  create  mission  threads.  The  mission  threads  formed  part  of  the  basts  for 
requirement*  development. 


2. 


Functional  Analysis  Phase 


a.  Requirements  Definition 

The  puiposc  of  the  Requirements  Definition  stage  of  the  project  was  to  identify  the 
functional  requirements  necessary'  to  accomplish  the  SUW  and  MIO  missions.  The  Stakeholder 
surveys  conducted  in  the  Needs  Analysis  phase,  along  with  the  mission  threads,  provided  the 
initial  direction  for  this  stage.  Once  the  broad  mission  functions  were  derived  from  the  surveys 
and  mission  thread  sequence  diagrams,  research  of  Navy  and  DoD  doctrine  and  policy 
publications  provided  an  additional  level  of  detail  for  the  requirements.  This  filled  in  some  areas 
that  had  been  unaddressed  and  expanded  on  those  that  were  already  addressed.  The  functional 
requirements  subsequently  populated  a  CORK  model,  described  below,  which  was  used  to 
validate  the  adequacy  of  the  function  list.  CORE  is  a  commercially  available  systems 
engineering  and  design  software  tool.  The  requirements  list  was  further  expanded  in  the  Value 
System  Design  stage  by  adding  performance  and  constraint  requirements  that  quantify  the 
capability  of  a  specific  instantiation  of  the  architecture.  Figure  5  summarizes  the  relationship  of 
the  Requirements  Definition  task  to  the  other  tasks. 


b.  Value  System  Design 


The  objective  of  the  Value  System  Design  was  to  bridge  together  the  stakeholder 
functional  needs  and  the  C2  requirements  by  using  the  mission  threads  and  Navy  Doctrine  to 
formulate  system  objectives  and  develop  threshold  values.  The  Value  System  Design  was  also 
used  to  develop  objectives  and  map  those  objectives  to  the  stakeholder  requirements  through  the 
use  of  associated  values  in  the  form  of  performance  measures.  Each  requirement  was  then 
mapped  to  the  function  that  it  supported  in  order  to  provide  full  traceability  between 
requirements  and  architecture  functionality.  Figure  6  summarizes  the  relationship  of  the  Value 
System  Design  Task  to  the  other  tasks. 


Figure  6:  Value  System  Design  Task  Relationships 

Information  from  the  Needs  Analysis  phase  and  the  Value  System  Design  were  used  to  develop 
the  C2  requirements.  The  C2  requirements  then  become  the  foundation  for  the  Architecture  and 
also  supported  the  Modeling  and  Analysis  phase. 


c  Enterprise  Architecture 

The  Hntcrprisc  Architecture  task  defined  the  functionality  of  the  C2  system  and  the  C2 
system’s  interfaces  with  other  systems.  The  architecture  was  developed  based  on  the  C2  system 
requirements  produced  during  the  Requirements  Definition  task.  As  the  architecture  was 


developed,  the  requirements  were  allocated  to  the  C2  system  functions.  This  ensured  that  the 
architecture  addressed  all  of  the  C2  system  requirements.  Figure  7  summarizes  the  relationship 
of  the  Fntcrprisc  Architecture  task  to  the  other  tasks. 
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Figure  7:  Enterprise  Architecture  Task  Relationships 
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(  2  Requirements  described  ibe  capability  of  the  system.  The  Enterprise  Architecture  task 
develops!  the  architecture  products. 


3.  Modeling  and  Analysis 

a.  Modeling  and  Simulation 

The  overall  objective  of  the  Modeling  and  Simulation  (M&S)  activities,  seen  in  Figure  8. 
was  to  verify  the  architecture  through  the  use  of  model-based  systems  engineering,  an  integral 
part  of  the  requirements  and  architecture  development  process.  M&S  was  used  to  verify  and 
improve  the  operational  and  the  functional  activity  models  that  were  derived  from  the 
architecture  and  based  on  the  requirements. 

Verification  was  accomplished  using  two  different  but  complementary,  M&S 
techniques:  discrete  event  simulation  and  Colored  Petri  Nets  (CPN).  The  purpose  of  this 
verification  ciTort  was  to  verify  that  the  architecture  was  complete,  internally  consistent  and 
executable.  The  discrete  event  simulation  was  also  used  to  create  a  dynamic  view  of  the  OV-5 
and  SV-4. 
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Figure  #:  Modeling  and  Simulation  Task  Relationships 

C2  Requirement*  described  the  capability  ot*  the  system.  The  Enterprise  Architecture  task 
dcvek)fxd  the  architecture  products. 


b.  Cost  Analysis 

The  Cost  Analysis  task  was  conducted  in  parallel  with  MAS  and  was  the  culminating 
activity  for  the  entire  project.  Activities  in  the  prior  phases  were  conducted  to  provide  input  (in 
the  form  of  the  architecture  products)  into  the  Cost  Analysis  task.  The  Cost  Analysis  task 
investigated  multiple  means  of  establishing  a  quantitative  measure  of  cost  comparison,  ultimately 
using  school  house  training  hours  as  the  metric.  The  architecture  functionality  was  compared 
with  available  training  information  from  two  combat  system  training  courses  to  investigate  if  a 
common  architecture  could  result  in  lifecycle  cost  sav  ings  (measured  in  terms  of  training  hours). 
Figure  9  summarizes  the  relationship  of  the  Cost  Analysis  task  to  the  other  tasks. 
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Figure  9:  Cost  Analysis  Task  Relationships 

Training  Infarmalxm  and  Ihc  Elntcrpri*c  Architecture  an:  u«d  to  estimate  potential  saving 
(measured  in  training  hour*)  that  could  be  achieved  by  using  a  common  set  of  C2  requirements 


I).  ASSUMPTIONS 

When  using  the  term  command  and  control,  the  project  makes  no  distinction  between  the 
human,  hardware,  software,  and  procedural  elements  of  the  system.  The  project  identifies  the 
functionality  of  command  and  control  as  it  applies  to  the  two  mission  threads.  The  project  docs 
not  further  decompose  the  functions  to  a  physical  architecture  where  distinctions  between 
human,  hardware  and  software  actions  would  become  more  evident.  In  other  words,  the  scope  of 
the  project  ends  at  defining  C2  functionality,  and  docs  not  identify  the  components  and 
procedures  necessary  to  achieve  the  functionality.  This  activity  is  left  to  the  trade  space  for 
follow-on  efforts. 

The  project  acknowledges  that  the  requirements  and  architecture  do  not  represent  a 
complete  set  of  C2  functionality.  Project  resource  constraints  were  prohibitive  in  producing  a 
comprehensive  C2  architecture  and  requirements  set.  However,  the  project  docs  demonstrate  a 
process  for  developing  common  requirements  and  architecture,  and  then  using  the  architecture  to 
identify  potential  areas  of  cost  savings.  It  is  the  expectation  of  the  project  team  that  this  process 
will  provide  valuable  insight,  and  will  be  sealable,  for  developmental  efforts  for  actual  systems. 
It  is  also  expected  that  the  requirements  and  architecture  products  produced  by  this  project  will 
provide  a  baseline  for  future  development  efforts. 
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II.  NEEDS  ANALYSIS 


The  System  Engineering  Process  began  with  the  Needs  Analysis  phase.  The  given 
problem  statement  was  refined  to  further  understand  the  needs  and  expectations  of  the 
stakeholders.  In  this  phase  the  mission  threads  were  researched  and  more  clearly  defined  as  part 
of  the  project  proposal.  The  threats  against  which  the  C2  architecture  and  requirements  must 
perform  were  also  identified.  These  tasks  occurred  in  parallel. 

A.  STAKEHOLDER  ANALYSIS 

L  Background 

The  objectives  of  the  stakeholder  analysis  were  to  identify  the  key  organizations  that  can 
affect  or  will  be  affected  by  the  development  of  the  ship  C2  system  and  also  to  identify 
stakeholder  objectives  and  requirements.  Stakeholders  included  interested  parties  such  as  future 
users,  system  developers,  and  resource  sponsors. 

The  output  of  the  stakeholder  analysis  was  a  summary  of  the  key  stakeholder  needs  and 
objectives  identified  from  stakeholders  and  their  documents.  The  stakeholder  needs  and 
objectives  served  to  frame  the  requirements  definition,  enterprise  architecture  and  value  system 
design  tasks  during  the  functional  analysis  phase  and  ensured  that  the  resulting  products  would 
satisfy  the  stakeholders. 

2.  Stakeholders 

A  full  range  of  stakeholders  were  identified  by  considering  the  operational  fleet 
organizations  and  the  decision  authonties  of  the  three  components  of  the  DoD  system  life-cycle 
processes:  the  Joint  Capabilities  Integration  and  Development  System  (JCTDS).  the  Defense 
Acquisition  System  (DAS)  and  the  Planning.  Programming.  Budgeting,  and  Execution  System 
(PPBES).  Figure  10  depicts  the  stakeholder  organizations  identified  and  their  organizational 
relationships.  Further  details  on  specific  organizations  that  were  identified  arc  provided  in  Table 


Secretary  oflhe  Navy 
SECNAV 


Assistant  Secretary  of  the 
Navy  for  Research, 
Development  and 
Acquisition 
ASN  (RD&A) 


Chief  of  Naval 
Operations 
(CNO) 


Fleet  Forces 
Command 


ASN  (RD&A)  Chief 
Systems  Engineer 
(ASN  RD&A  CHSENG) 


System 

Commands 

(SYSCOM) 


Pacific  Fleet 


Program  Executive 
Offices 
(PF.O) 


Deputy  Assistant 
Secretaries  of  the  Navy 
(DASN) 


Figure  10:  Stakeholder  Organizational  Relationships 


<  nYt«v  nf  iHa 

Atlantic  Fleet 

CNO 

(OPNAV) 

These  arc  the  organizations  identified  by  the  projecl  as  stakeholders.  Figure  10  indicates  the 
oruani/atimal  relationship  between  these  organizations.  The  dashed  line  represents  the 
coordination  and  support  role  that  Fleet  Forces  Command  provides  to  sustain  the  Heel. 
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Table  I:  Stakeholder  Organizations  and  Roles 


This  table  identifies  the  oreani/alKins  and  dewnbe*  the  roles  of  the  stakeholder  organi/nisom 
identified  for  this  project.  (From  Department  of  the  Navy,  Research.  Desdopment  and 
Acquisition.  "ASN  RDA '.  2009;  Navy.mil,  "The  Operating  Forces'*.  2009;  Navy  mil.  "The 
Secretary  of  the  Navy".  2009;  Navy  . mil.  "Th:  Shore  Establishment".  2009] 


Responsible  for  all  affairs  of  the  IJ.S. 
Navy. _ 

Executes  the  Joint  Capabilities  Integration 
and  Development  System  ami  Planning. 
Programming.  Budgeting,  and  Execution 
System,  defining  requirements  and 
budgeting  for  IJ.S.  Navy  systems. 


Secretary  of  the  Navy  (SECNAV) 


Office  of  the  Chief  of  Naval  Operations 

(OP.N.AV) _ 

NX5  (Director,  Expeditionary  Warfare) 

NS6  1  Director.  Surface  Warfare) _ 

NXS  (Director.  Air  Warfare) _ 

N6F  (Director.  Warfare  Integration) 

Meet  Force  Command _ 

Atlantic  Elect _ 

Pacific  Elect _ 

Assistant  Secretary  of  the  Navy  for 
Research.  Development  &  Acquisition 
(ASN  (RD&A)) 


Trains,  equips  and  mans  the  fleet 


U.S.  Navy  decision  authority  in  the 
Defense  Acquisition  System. 


ir'iicn  r".  1  iiniviv.i  wsviuu  i.iuiuvvi  in; 

Chief  Systems  Engineer  (CHSENG)  ,,  '  ...  ' 

_ _ guidance  to  Navy  acquisition. _ 

System  Commands _ 

Naval  Sea  Systems  Command 

(NAVSEA) _  Provide  engineering  personnel  under 

laval  Air  Systems  Command  (NAVAIR)  matrix  arrangement  with  the  PEOs. 
Space  and  Naval  Warfare  Systems 

Command  (SPAWARI _ 

Program  Executive  Offices 


led  Warfare  Systems  (IWS) 


Responsible  for  execution  of  the  Defense 
Acquisition  System. 


Unmanned  Aviation  a 


e  Weapons 


(L&W) _ 

Littoral  and  Mine  Warfare  ( l.M W) 
Deputy  Assistant  Secretaries  of  the 

Navy  (DASN) _ 

Ships  IWS _ 

Air 


Oversee  major  U.S.  Navy  acquisition 
programs  for  ASN  (RD&A). 
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Several  stakeholders  were  identified  to  support  this  project  execution.  These 
stakeholders  have  worked,  or  arc  currently  working,  in  the  C2  requirements  and  architecture 
areas.  They  have  provided  valuable  input  to  the  project  throughout  the  process.  These 
stakeholders  are  listed  below  in  Table  2. 


Table  2:  Project  Stakeholders 


Thu  i*  a  list  of  the  identified  stakeholder*  who  \%>rrc  able  ti>  participate  in  the  project.  These 
stakeholders  acted  a*  advisor*  and  provided  input  and  guidance  to  the  project  team. 


1  ^ 

Marc  Stockbaucr 

OPNAV  NX64 

Science  and  Technology  Advisor  for  the  Maritime 
Warfarc/Surfacc  Strike  Branch  (N864). 

Represents  N864  interests  in  the  approval  and 
execution  of  ongoing  and  proposed  Future  Naval 

C  apabilities  (FNC).  Joint  Capability  Technology 
Demonstrations  (JCTD),  Rapid  Technology 
Transitions  (RTT),  Rapid  Development  and 
Deployment  <RDD)  and  Defense  Advanced 

Research  Projects  Agency  (DARPA)  efforts. 

(hi  (ioddin 

Naval  Surface 
Warfare  Ccnlcr. 
Dahlgrcn 

Senior  Systems  Engineer  in  the  Warfare  Systems 
Department.  Warfare  Systems  Engineering  and 
Analysis  Division  and  serves  as  Warfare  Systems 
Definition  Branch  head.  Serves  as  the  cntciprisc 
Systems  Engineer  who  works  with  Program 
Executive  Office  <  PEO)  Integrated  Warfare 

Systems  (1 WS)  to  define  commonality  across 
platforms  for  combat  system  design. 

Tim  Neel 

Naval  Surface 
Warfare  Center, 
Dahlgrcn 

Senior  Combat  Control  Systems  Engineer  in  the 
Warfare  Systems  Department,  Combat  Control 
Division.  Develops  advanced  C2  architectures  for 
Surface  Navy  Combat  Systems. 

Doug  Haas 

Naval  Surface 
Warfare  Center, 
Dahlgrcn 

Senior  Technical  Advisor  to  the  Warfare  Systems 
Department.  Combat  Control  Division.  Supports 
the  department  for  combat  control  systems 
cnginccnng  matters  regarding  the  continued 
advanced  development  of  surface  combatants. 
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3. 


Methodology 


The  stakeholder  analysis  consisted  of  an  evaluation  of  both  Joint  and  Navy  guidance  and 
doctrine.  Interviews  with  stakeholders  helped  to  identify  the  objectives  and  development 
considerations  that  drove  the  architecture  and  requirements  of  the  ship  C2  system.  In  the 
evaluation  of  stakeholder  documents,  a  full  range  of  guidance  was  considered,  from  overarching 
maritime  policy  to  surface  warfare  tactics,  techniques,  and  procedures  (TTP).  The  documents 
used  in  this  analysis  included  U.S.  Naval  guidance,  the  Joint  Functional  C  oncepts  (JFC)  and 
Joint  Integrating  Concepts  (JIC)  from  the  Joint  Chiefs  of  Staff  and  U.S.  Naval  doctrine,  which 
arc  listed  in  Table  3.  U.S.  Naval  guidance  defines  the  missions  the  tJ.S.  Navy  perfomis  and  key 
characteristics  of  U.S.  Navy  performance.  The  JFC  define  the  functional  capabilities  of  the  joint 
force  while  the  JIC  define  tasks,  conditions,  and  standards  (Chairman  of  the  Joint  Chiefs  of  Staff 
3010.01  B.  2006].  U.S.  Naval  doctrine  defines  how  the  U.S.  Navy  conducts  its  missions, 
specifically  how  C2  is  executed  within  the  Surface  Warfare  and  Mantime  Interception 
Operations  missions. 


I  able  3:  Stakeholder  Analysis  Document  List 

Thu  is  a  list  of  the  Joint  and  Navy  publication*  that  wen  researched  for  this  project.  Infomiation 
gathered  from  these  documents  shaped  the  requirements  and  architecture  development  cfToctc. 


"A  Cooperative  Strategy  for  21st  Century  Scapowcr"  [United  States  Navy/United  States 
Coast  Guard.  2007) 


ions  Concept"  (United  States  Navy/United  States  Marine  C 


"Functional  Concept  for  Battlcspacc  Awareness"  [United  States  Department  of  Defense 
2003 1 


"Command  and  Control  Joint  Integrating  Concept"  [United  States  Department  of  Detense 
2005 1 


Universal  Naval  Task  List"  [Chief  of  Naval  Operations.  2007] 


'Navy  Surface  Warfare  Manual"  [Office  of  the  Chief  of  Naval 


The  information  gathered  from  the  documents  above  was  used  to  begin  the 
requirements  listing  and  was  used  to  develop  interview  questions  for  the  participating  project 
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stakeholders.  A  common  set  of  questions  were  presented  to  each  of  the  stakeholder  (reference 
Appendix  B).  The  comments  received  were  integrated  with  the  mam  points  from  the  guidance 
and  doctrinal  publications  and  arc  described  in  the  following  sections. 

The  results  of  this  analysis  were  then  divided  into  four  sections:  operational  settings  and 
threats;  tasks  and  functionality;  values  and  metrics;  and  acquisition  guidance.  Each  section 
supported  follow-on  tasks  in  the  Needs  Analysis  and  the  Requirements  Analysis  phases  of  the 
project.  The  stakeholder  analysis  also  identified  several  items  of  information  within  the  SUW 
and  MIO  TTPs  that  supported  the  mission  thread  and  architecture  development.  These  items 
included  mission  types,  command  organization  and  system  interface  requirements.  To  avoid 
duplication,  these  items  were  directly  incorporated  into  the  mission  thread  and  architecture 
sections. 


4.  General  Results 

a.  Operational  Settings  and  Threats 

National-level  defense  guidance  defines  the  missions  the  U.S.  Navy  is  expected  to 
perform  in  the  future  as  well  as  the  key  characteristics  of  U.S.  Navy  performance.  MA 
Cooperative  Strategy  for  21st  Century  Scapoxver’  detines  the  following  missions  for  naval 
forces:  forward  presence,  dctcirence.  sea  control*  power  projection,  and  maritime  security 
[United  States  Marine  Coip&'Unitcd  States  Navy/United  States  Coast  Guard.  20O7|.  However, 
the  Naval  Operating  Concept  (NOC)  cites  that  the  geographic  focus  of  these  missions  are 
changing  to  emerging  areas  such  as  Africa,  South  America  and  Indonesia,  specifically  the  Strait 
of  Malacca  (United  States  Navy/lJnited  States  Marine  Corps.  2006].  The  changing  geographic 
focus  is  important  since  the  worst-case  environmental  conditions  the  U.S.  Navy  may  face,  such 
as  sea  state,  atmospheric  conditions,  clutter  levels,  will  drive  the  requirements  on  the  C2  system 
[Goddin.  2008|. 

Threats  were  divided  into  traditional  and  irregular  threats.  Traditional  threats  to  naval 
platforms  include  a  wide  variety  of  weapons  from  surface  combatants,  submarines,  aircraft  and 
coastal  defenses.  Traditional  weapons  that  may  be  employed  against  naval  platforms  include 
Anti-Ship  Cruise  Missiles  (ASCM).  air-to-surfacc  missiles  and  bombs,  mines,  torpedoes,  naval 
guns,  and  rocket  projectiles  [Office  of  the  Chief  of  Naval  Operations.  2007|. 


Irregular  threats  span  from  smaller  craft  and  Unmanned  Aerial  Vehicles  (UAVs)  to 
catastrophic  threats.  Fast  attack  craft  use  crew-served  weapons,  rockets,  ASCM,  wake-homing 
torpedoes  and  water-borne  Improvised  Explosive  Devices  (IED)  as  a  threat  in  littoral  waters 
(Office  of  the  Chief  of  Naval  Operations.  2007).  The  small  boat  threat  is  of  specific  concern, 
including  crafi  as  small  as  personal  watercraft.  This  threat  is  further  complicated  in  a  high- 
clutter.  high  sea  state  operational  environment  ((ioddin.  2008 J.  Aircraft,  such  as  small  planes 
and  UAVs,  submcrsiblcs.  and  commercial  platforms  pose  potential  harm.  Criminal 
organizations  and  piracy  have  evolved  with  organized  attacks  and  improved  communications 
systems  and  weapons.  Disruptive  information  technology,  directed  energy,  and  cyber  terror  also 
pose  as  threats  to  naval  platforms.  Catastrophic  threats,  namely  Weapons  of  Mass  Destruction 
(WMD)  remain  a  threat  as  well  (Office  of  the  Chief  of  Naval  Operations.  20()7|. 

b.  Tasks  and  Functionality 

The  “Universal  Naval  Task  List"  (UNTL).  Version  3.0  defines  the  tasks  that  the  U.S. 
Navy  performs.  In  particular.  Chapter  3  defines  the  tactical-level  tasks  in  the  Navy  Tactical  Task 
List  (NTTL).  The  NTTL  was  a  useful  tool  to  assess  the  range  of  tasks  that  the  ship  C2  system 
should  be  able  to  support.  Four  major  Navy  Tactical  Tasks  (NTA)  were  identified  to  scope  the 
ship  C2  system  architecture: 

•  Conduct  Counter-mobility  (NTA  1.4). 

•  Perform  Collection  Operations  and  Management  (NTA  2.2), 

•  Process  Targets  (NTA  3. 1 ),  and 

•  Acquire.  Process.  Communicate  Information  and  Maintain  Status  (NTA  5.1) 
(Chief  of  Naval  Operations.  Commandant  of  the  Marine  Corps.  20()7|. 

The  tactical  tasks  arc  further  decomposed  in  Table  4. 
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Table  4:  Navy  Tactical  Tasks 

These  arc  the  NT  As  lhal  were  used  as  the  outline  to  develop  tlic  requirements  and  architecture. 


1.4 

Conduct  Counter-mobility:  "To  construct  obstacles  and  employ  area  denial 
efforts  including  mines  to  delay,  disrupt,  and  destroy  the  enemy.  The 
primary  purpose  of  counter- mobility  operations  is  to  slow  or  divert  the 
enemy,  to  increase  time  for  target  acquisition,  and  to  increase  weapons 
effectiveness."  [UNTL  v  3.0:  3-B-16  -  3-B-2()| 

1.4.6 

Conduct  Maritime  Interception 

1 .4.6.1 

Conduct  Visit 

1. 4.6.3 

Conduct  Seizure 

2.2 

Perform  Collection  Operations  and  Management:  "To  gather  data, 
information,  and  previously  produced  intelligence  from  all  sources  to  satisfy 
the  identified  requirements."  (UNTL  v  3.0:  3-B-33  -  3-B-35| 

2.2.1 

2.2. 1.1 

Detect  Contacts 

Track  Contacts 

2.2. 1.3 

Classify  Contacts 

2.2. 1.4 

Identify  Contacts 

2.2. 1.5 

Localize  Contacts 

3.1 

Process  I  argets:  To  positively  identify  and  select  land.  sea.  and  air  targets 
that  decisively  impact  battles  and  engagements  and  match  targets  with 
appropriate  firepower  systems  ..."  |UNTL  v  3.0:  3-B-44  -  3-B-45| 

3.1.1 

Request  Attack 

3.1.2 

3.1.3 

Select  Platform(s)  and  Systcmls)  for  Attack 

3.1.4 

Develop  Order  to  Fire 

3.1.5 

Conduct  Tactical  (  ombat  Assessment 

5.1 

Acquire,  Process.  Communicate  Information  and  Maintain  Status:  “To 

obtain  information  on  the  mission,  enemy  forces,  ncutral'non-combatants. 
friendly  forces,  terrain,  and  weather.  To  translate  that  information  into 
usable  form  and  to  retain  and  disseminate  it."  |  UNTL  v  3.0:  3-B-91  -  3-B- 
94 1 

5.1.3 

Maintain  Information  and  Naval  Force  Status 

5.1. 3.1 

Maintain  and  Display  Tactical  Picture 

. . .  . ■■  ■■ 

5.1. 3. 3 

Maintain  and  Display  Units  Readiness 

The  listing  of  Navy  tactical  tasks  is  limited  to  the  detection,  tracking,  classification, 
identification,  and  reporting  and  boarding  of  surface  threats  as  well  as  the  detection,  tracking, 
identification,  and  reporting  of  merchant  ships  during  MIO.  NTA  (Navy  Tactical  level  of  war 
tasks!  1.4.6  addresses  the  conduct  of  Visit.  Board.  Search  and  Seizure  (VBSS).  NTA  2.2.1 
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covers  the  detection,  tracking,  classification  and  identification  of  contacts.  NTA  3.1.1  includes 
C2  tasks  associated  with  threat  evaluation  and  weapons  assignment.  NTA  5.1.3  focuses  on 
threat  and  status  reporting. 

The  “Navy  Surface  Warfare  Manual”  defines  a  comparative  set  of  top-level  functions, 
termed  the  Surface  Warfare  kill  chain,  which  was  directly  applicable  to  the  project  requirements 
and  architecture  development  efforts.  The  components  of  that  kill  chain  arc:  find.  fix.  track, 
target,  engage,  and  assess  (Office  of  the  Chief  of  Naval  Operations.  2007 1.‘ 

•  Find:  Monitor  environment 

•  Fix:  Localize  the  potential  target 

•  Track:  Maintain  continuous  track 

•  Target:  Cheek  for  Rules  of  Engagement  (ROE)  and  coordination  measures  and  match 
weapon  and  sensor  to  target 

•  Engage:  Issue  the  engagement  order  and  create  effects  on  target 

•  Assess:  Assess  where  desired  effects  were  achieved,  including  physical  and  functional 
damage 

Within  the  find.  fix.  and  track  phases,  off-board  platforms  such  as  helicopters.  IJAVs  and 
Unmanned  Surface  Vehicles  (USV)  play  an  extensive  role  to  extend  detection  ranges.  The 
integration  of  those  sensors  into  the  tactical  picture  may  be  considered  a  key  factor  (Haas  and 
Neel.  20<)8|.  Also.  Chemical.  Biological  and  Nuclear  (CBN)  scnson>.  either  shipboard  or  on 
UAV  or  USV,  play  a  role  in  identifying  standoff  ranges  for  threats  (Stockbauer.  2(M)X|. 

Within  the  target  phase  of  the  kill  chain,  the  principles  of  preplanned  responses  have 
significant  impacts  for  the  ship  C2  system.  “Preplanned  responses  will  be  executed  for  all 
critical  and  unknown  surface  contacts  that  may  enter  into  the  SUW  AO  as  established  by  the 
strike  group  commander”  (Office  of  the  Chief  of  Naval  Operations.  2007 J.  This  implies  that 
there  is  a  requirement  for  the  ship  C2  system  to  be  able  to  provide  automated  decision  support 
based  on  preplanned  responses  to  any  and  all  surface  contacts. 


'The  project  use*  the  kill  chain  terminology  as  defined  by  the  Navy  in  “Navy  Warfare  Publication:  Navy  Surface 
War  tare  Manual  NWP  3-20“.  which  is  consistent  with  the  Joint  document  NTTP  3-60. 1 
■'MULTI-SERVICE  TACTICS,  TECHNIQUES,  AND  PROCEDURES  FOR  TARGETING 

TIME-SENSITIVE  TARGETS",  dated  April  2004.  Other  documents  exist  (eg.  the  Capabilities  Based  Assessment 
Users  Guide.  December  2006.  JCS  J-8)  which  use  slightly  different  terminology  for  the  kill  chain. 
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Part  of  preplanned  responses,  is  support  for  automated  identification.  For  surface 
contacts,  this  includes  detection  of  a  muzzle  flash  by  an  EIcctro-OpticaLinfra-Red  (EO.iR) 
sensor,  range  rings.  Identification  Friend  or  Foe  (IFF)  returns,  or  kinetic  information.  The  next 
step  is  support  for  an  auto-engage  capability  that  can  be  configured  and  initiated  by  the  operator 
| Haas  and  Neel,  2008). 

The  engage  phase  of  the  kill  chain  is  not  limited  to  kinetic  effects.  Non-kinctic  effects 
arc  expected  to  have  a  growing  influence  in  future  SUW  and  MIO  missions,  especially  against 
small  boats.  Potential  non-kinctic  effects  included  Radio  Frequency  (RF)  weapons  to  disable 
engines  and  prop-foulmg  devices  [Haas  and  Neel.  2008].  Non-damaging  effects  are  a  specific 
subset  of  non-kinctic  effects  for  use  in  commercial  and  civilian  maritime  craft  interdiction 
IStockhaucr.  2008]. 

Success  in  a  SUW  mission  depends  upon  the  ability  to  make  better  decisions  faster  than 
the  enemy  can  react  to  them,  known  as  decision  superiority  (Office  of  the  Chief  of  Naval 
Operations.  2007].  Decision  superiority  consists  of  two  elements,  information  superiority  and 
knowledge  superiority.  Information  superiority  is  defined  as  "the  operational  advantage  derived 
from  the  ability  to  collect,  process,  disseminate,  and  display  an  uninterrupted  flow'  of  tactically 
and  strategically  relevant  infomiation  while  exploiting  or  denying  an  adversary's  ability  to  do  the 
same"  (Office  of  the  Chief  of  Naval  Operations.  2007.  1-8].  The  Department  of  Defense 
Dictionary  of  Military  and  Associated  Terms  includes  a  similar  definition  of  information 
superiority  (Joint  Staff.  2008].  Knowledge  superiority  is  the  advantage  over  the  enemy  in 
education,  training,  and  experience  (Office  of  the  Chief  of  Naval  Operations.  2007], 

The  ability  to  accurately  identity  friend,  neutral,  and  hostile  ships  in  a  saturated 
environment  is  a  major  factor  in  decision  superiority  (Haas  and  Neel.  200X;  Stockbaucr.  2008: 
(ioddin.  2008).  This  involves  the  integration  of  all  available  sensor  sources  and  Indications  & 
Warnings  (I&W)  that  support  accurate  determinations  of  identity  that  can  be  acted  upon  with 
high  degrees  of  confidence.  This  includes  the  integration  of  EO/IR  and  acoustic  data  into  the 
tactical  picture.  This  high  volume  of  data  leads  to  the  need  for  tailor-able  tactical  and 
operational  pictures  where  the  data  displayed  is  driven  by  the  mission  requirements  (Haas  and 

Neel.  2008]. 

Other  major  concepts  include  Distributed  Weapons  Control,  and  Engage  on  Remote. 
Both  concepts  depend  on  real-time  sensor  netting.  Real-time  sensor  netting  is  the  sharing  of 
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sensor  data  to  ensure  a  common  picture  across  platfomis.  Distributed  Weapons  Control  includes 
the  distributed  coordination  of  engagements  while  Engage  on  Remote  is  the  ability  to  engage 
targets  using  sensor  data  from  another  platform.  The  keys  to  Distributed  Weapons  Control. 
Kngage  on  Remote  and  real-time  sensor  netting  arc  time  accuracy,  navigation  accuracy,  and  data 
registration  (Haas  and  Neel.  2(M)X|. 

Several  key  needs  specific  to  the  MIO  mission  were  also  identified  during  Stakeholder 
Analysis.  Maintenance  of  the  surface  picture  was  an  ov  erarching  element  of  MIO.  Maintenance 
of  the  surface  picture  includes:  accounting  for  all  surface  contacts  by  name,  track  number  and 
MIO  control  contact  number,  maintaining  query  and  boarding  status  of  each  surface  contact, 
updating  and  maintaining  the  tactical  data  link,  and  promulgate  surface  situation  reports 
(SITRKPs)  (United  States  Navy, -United  States  Coast  Guard.  2003). 

The  C2  system  needs  to  be  able  to  integrate  intelligence  data  into  the  MIO  tactical 
picture.  The  Maritime  Intercept  Commander  (MIC)  Intelligence  Officer  needs  to  have  the  ability 
to  draw  from  data  from  several  organizations  and  data  sources  that  can  be  used  to  support  the 
classification  and  identification  of  commercial  vessels,  including:  Office  of  Naval  Intelligence 
(ONI)  Maritime  Target  Development  Division  National  Maritime  Intelligence  Center.  Office  of 
Naval  Intelligence  Merchant  Ship  C  haracteristics  Hidden  Compartment  Book,  and  Scalink 
Databases  of  Vessels  Electronic  Intelligence  parameters  correlated  to  known  sanctions  violators 
(United  States  Navy.’Umted  States  Coast  (iuard.  2003). 

The  Automatic  Identification  System  (AIS)  resides  on  commercial  and  naval  ships  and 
broadcasts  ship  information  in  the  Very  High  Frequency  (VHF)  maritime  band.  The  AIS 
transponder  broadcasts  ship  name,  classification,  call  sign,  registration  number,  course  and 
speed,  and  the  International  Telecommunications  Union  Maritime  Mobile  Service  Identity 
(MMSI)  to  other  AlS-cquippcd  ships  (United  States  Coast  Guard.  200SJ.  This  ability  enables 
AlS-equippcd  ships  conducting  MIO  operations  to  correlate  ship  names  with  intelligence 
databases  prior  to  first  interrogation.  Of  course.  AIS  is  a  cooperative  system,  meaning  that  a 
vessel  that  does  not  want  to  be  easily  identified  can  disable  its  AIS  broadcast  system. 


c  Values  and  Metrics 


A  wide  array  of  metrics  applies  to  the  ship  C2  system.  Common  metrics  include 
Operational  Availability  (A0,  (Cioddin.  2008)  and  required  bandwidth  |Stockbaucr.  200S). 
Operational  availability  is  a  measure  of  the  degree  to  which  one  can  expect  a  system  to  work 
properly  when  required.  (Defense  Acquisition  University.  2005 1. 

Other  programs  completed  extensive  work  in  the  development  of  C2  related  metrics.  The 
Single  Integrated  Air  Picture  (SIAP)  developed  a  suite  of  metrics  relating  to  the  common  tactical 
and  operating  pictures  that  can  be  adapted  to  the  surface  picture  [Stockbauer.  2008).  Key 
metrics  from  the  SIAP  Attributes  (Single  Integrated  Air  Picture  System  Engineering  Task  Force. 
2003 1  that  will  serve  as  a  basis  for  key  C2  system  performance  requirements  include: 

•  Clarity:  (Ambiguous  Tracks)  The  percentage  of  real  world  objects  that  have  more  than 
one  track  assigned.  (Spurious  Tracks)  The  percentage  of  tracks  w  ithout  a  corresponding 
real  world  objects. 

•  Continuity:  The  number  of  track  numbers  assigned  to  each  real  world  object. 

•  Identification  Completeness:  The  percentage  of  tracked  objects  that  arc  in  an  identified 
state. 

•  Identification  Correctness:  The  percentage  of  tracked  objects  that  have  the  correct 
identification. 

d.  Acquisition  Guidance 

PI£()  IWS  has  developed  a  vision  for  the  engineering  of  future  surface  navy  combat 
systems.  Much  of  the  vision  provided  is  directly  applicable  to  the  development  of  the  C2  system 
architecture  and  requirements.  The  PEO  IWS  vision  is  based  on  three  major  principles:  a 
componenti/cd  system  architecture  using  open  information  standards;  a  system  product  line 
developed  based  on  a  common,  objective  architecture;  and  a  decoupling  of  system  development 
from  platform  development  while  still  accommodating  platform-specific  needs  (Benedict  2008 J. 
In  line  with  this  strategy,  the  stakeholder*  provided  specific  acquisition  guidance  that  ensures  the 
C2  system  design  will  support  the  future  engineering  vision  for  surface  navy  combat  systems. 

For  existing  platforms,  the  C2  system  should  have  no  impact  to  Cruiser-Destroyer 
manning  requirements  and  no  adverse  impact  to  physical  C2  spaces  (Stockbauer.  2008].  For 
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existing  and  new  platforms,  the  C2  system  must  apply  Modular  Open  Systems  Architecture 
(MOSA)  design  principles  (Under  Secretary  of  Defense  for  Acquisition,  Technology  and 
Logistics.  2003;  Stockbauer.  2008]  and  maintain  independence  of  the  C2  system  application 
from  the  underlying  Commcrcial-Ofl-Thc-Shclf  (COTS)  computing  plant  (Stockbauer.  2008].  A 
MOSA  design  is  defined  by  key  principles:  use  of  a  modular  design,  definition  of  key  interfaces 
and  use  of  open  standards.  A  modular  design  involves  the  development  of  components  that 
implement  cohesive  functionality,  hide  the  inner  workings  of  the  component,  limit  impacts  to 
other  components  and  enable  component  reuse  (Defense  Acquisition  University,  2009]. 

All  of  the  standards  employed  by  the  ship  C2  system  must  be  consistent  with  the  DoD 
Information  Technology  Standards  Repository  (DISR)  as  dictated  by  CJCS  Instruction  6212.01. 
Interoperability  and  Supportability  of  Information  Technology  and  National  Security  Systems 
(Stockbauer.  2008:  Defense  Acquisition  University.  2009]. 

All  life-cycle  considerations  need  to  be  examined  for  the  ship  C2  system  architecture. 
Specifically  training,  including  training  timelines,  schoolhousc  requirements,  and  cost  must  be 
considered  during  development  (Stockbauer.  2008 1. 

5.  Stakeholders  Analysis  Conclusions 

The  stakeholder  analysis  was  conducted  by  surveying  publications  that  ranged  from  U.S. 
Naval  guidance  to  tactics,  techniques  and  procedures  and  by  interviewing  the  project 
stakeholders.  Through  analysis  several  key  stakeholder  needs  and  objectives  were  identified. 
These  results  were  divided  into  operational  settings  and  threats,  tasks  and  functionality,  values 
and  metrics,  and  acquisition  guidance.  These  needs  and  objectives  were  summarized  and  used  to 
support  subsequent  tasks. 

The  stakeholder  analysis  identified  a  categorization  of  threats  that  served  as  the  basis 
for  the  threat  assessment.  The  threat  categories  included  traditional  threats  to  naval  platforms: 
surface  combatants,  submarines,  aircraft  and  coastal  defenses.  Threat  weapons  included  ASCM. 
air-to-surfacc  missiles  and  bombs,  mines,  torpedoes,  naval  guns,  and  rocket  projectiles  (Office  of 
the  Chief  of  Naval  Operations.  2007].  The  threat  categories  also  included  irregular  threats  such 
as:  fast  attack  craft  (FAC)  and  small  boats,  small  planes  and  UAVs,  submcrsiblcs.  commercial 
platforms,  criminal  and  piracy  organizations,  disruptive  infoimation  technology,  directed  energy, 
cyber  terror  and  WMD  (Office  of  the  Chief  of  Naval  Operations.  2007;  Goddin.  2008]. 
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The  stakeholder  analysis  also  identified  several  key  functional  needs  from  the 
stakeholders.  These  needs  arc  summarized  in  Table  5. 


Table  5:  Stakeholder  Functional  Needs 

TaMc  5  summarizes  the  key  function  needs  identified  during  the  Stakeholder  Analysis  phase  of 
the  prefect. 


Support  the  entire  SUW  kill  chain  (find,  fix,  track,  target,  engage  and  assess)  (Office 

of  the  Chief  of  Naval  Operations.  2007] _ 

Positively  identify  contacts  using  all  available  sensors  (Cioddin.  200S;  Haas  and  Neel. 

2008] _ 

Integrate  off-board  sensors  into  the  tactical  picture  (Haas  and  Neel.  20081 _ 

Support  automated  identification  (c.g.  detection  of  muzzle  flashes  with  an  HO  IR 

sensor,  range  rings.  IFF  returns  or  kinetic  information)  (Haas  and  Neel.  20QX] _ 

Support  distributed  weapons  control  and  real-time  sensor  netting  (Haas  and  Neel, 

2008] _ 

Support  pre-planned  responses  ( PPR }  (Office  of  the  Chief  of  Naval  Operations.  2007] 

Hmploy  non-kinetie  and  non-damaging  effects  [Stockbauer.  2008] _ 

Maintain  the  MIO  picture,  including  query  and  boarding  status,  track  reporting  and 

SITRKPs  [United  States  Navy/United  Stales  Coast  Guard.  20031 _ 

Integrate  intelligence  data  into  the  MIO  tactical  picture  (United  States  Navy/United 

States  Coast  Guard.  2003] _ 

Integrate  AIS  data  into  MIO  contact  classification  and  identification  (United  States 
Coast  Guard.  2008) 


The  overarching  stakeholder  objective  was  decision  superiority.  This  translated  into 
metrics  needed  to  assess  the  accuracy  and  speed  with  which  the  C2  system  would  distinguish 
between  neutral  and  hostile  contacts  in  a  saturated  environment,  including  track  picture  clarity, 
continuity,  identification  completeness  and  identification  correctness  (Haas  and  Neel.  2008: 
Goddin.  2008:  Single  Integrated  Air  Picture  System  Engineering  Task  Force,  2003).  Required 
values  will  be  addressed  in  Section  III.  A  of  this  report. 

The  stakeholder  analysis  was  also  used  to  elicit  specific  guidance  on  the  acquisition  of 
the  ship  C2  system.  This  guidance  was  used  to  drive  the  development  of  the  C2  system 
architecture.  Specific  guidance  on  the  C2  system  architecture  included:  no  impact  to  manning: 
must  use  a  MOSA  design:  and  must  minimize  life-cycle  impacts. 
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B.  MISSION  THREADS  ANALYSIS 


L  Background 

A  mission  thread  is  a  descriptive  process  that  entails  what  actions  the  systems  must 
perform  in  a  specified  area  of  operation  and  includes  the  people,  hardware,  and  software  that  arc 
involved  in  performing  these  missions.  Mission  threads  arc  generally  derived  from  existing 
doctrine,  such  as  the  Naval  Task  List  ami  stakeholder  needs  and  wants  that  suggest  several 
missions  that  a  task  force  or  battle  group  system  should  perform.  The  mission  thread  analysis 
utilized  the  doctrine  identified  in  the  Stakeholder  Analysis  as  input  to  the  mission  thread 
definition. 

Mission  threads  were  needed  for  several  reasons:  identifying  system  functionality, 
identifying  a  reasonable  operational  environment  in  which  the  system  would  be  expected  to 
perform,  and  defining  system  boundaries.  In  addition,  mission  thread  analysis  facilitated  in 
generating  C2  requirements  for  the  project.  It  should  be  noted  that  for  both  SUW  and  MIO 
mission  threads.  C2  includes  functionality  that  would  be  assigned  to  shipboard  personnel, 
hardware  and  software  required  to  perform  the  mission.  The  outputs  of  the  mission  threads 
analysis  included  boundaries,  high  level  interface  definition,  and  functionality  required  to  meet 
the  stakeholder  needs  identified  in  the  Needs  Analysis  phase  of  the  project. 

2.  Methodology 

A  mission  threads  analysis  was  performed  to  further  define  the  threads  identified  in  the 
project  proposal.  The  threads  aided  in  the  development  of  the  C2  architecture  and  requirements. 
A  representative  operational  scenario  was  identified  to  demonstrate  the  functionality  that  a  C2 
Architecture  would  be  expected  to  perfomi  to  support  the  mission.  The  inputs  from  the 
stakeholder  analysis,  navy  doctnnc.  ami  publications  were  then  organized  into  a  scenario  and 
ev  ent  sequence  that  was  consistent  with  existing  doctrine.  The  threads  include  a  text  description 
of  the  scenario  and  an  activity  diagram  depicting  the  operational  nodes  and  the  functionality 
conducted  to  complete  the  mission.  The  operational  nodes  arc  represented  as  column  headers, 
and  the  activities  performed  by  each  node  arc  represented  by  the  graphics  in  each  column.  Both 
threads,  SUW  and  MIO,  have  an  operational  node  labeled  "Command  and  Control"  which 
represents  the  functionality  of  the  project  C2  system.  All  activities  in  the  "Command  and 
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Control**  column  (swim  lane)  arc  considered  part  of  the  C2  system.  All  other  activities  arc 
necessary  to  complete  the  mission,  but  arc  considered  outside  the  boundary  of  the  C2  System 
functionality. 

The  mission  threads  analysis  confines  the  multiple  and  diverse  missions  roles  that  a  C2 
architecture  should  be  capable  of  and  focuses  the  analysis  and  boundaries  of  the  project  on  two 
particular  mission  threads  that  arc  diverse  enough,  yet  stress  C2  system  interfaces  to  simulate 
operating  in  a  real  world  environment.  Furthermore,  the  threads  were  used  in  the  development 
of  the  OV-ls  and  C2  requirements.  Upon  further  input  from  the  threat  assessment,  the  mission 
threads  were  refined  to  support  the  requirements  and  architecture  defined  in  later  sections. 

3.  Surface  Warfare 

a.  Overview 

The  Surface  Warfare  (SIJW)  mission  thread  depicts  a  surface  warfare  activity,  focused 
particularly  on  the  C2  system  aboard  a  Navy  combatant  platform  while  executing  the  SUW  kill 
chain  process  [Office  of  the  Chief  of  Naval  Operations.  2(K)7|  in  open  ocean  operations.  The 
thread  is  divided  into  three  "swim  lanes":  Sensor  Systems.  C2.  and  Engagement  Systems.  This 
thread  focused  on  the  C2  functions,  processes,  and  interfaces  required  in  supporting  the  mission. 

b.  Scenario  Baseline  Description 

A  surface  action  group  (SAG)  [Office  of  the  Chief  of  Naval  Operations.  2007|  consists  of 
two  guided  missile  destroyers  (DDG)  and  one  guided  missile  frigate  (FFG>  defending  the 
maritime  maneuver  area  in  the  Indian  Ocean.  All  ships  have  Condition  III  watch  stations 
manned.  Condition  III  is  defined  as  a  wartime  steaming  with  at  least  half  of  the  systems  at  a 
ready  status  at  all  times  (Cutler.  20081.  Each  destroyer  has  one  embarked  helicopter  to  support 
over-the-horizon  (OTH)  search  and  targeting  capabilities.  The  purpose  of  the  maritime 
maneuver  area  defense  operations,  as  has  been  seen  in  traditional  roles,  is  to  protect  the  friendly 
sea  line  of  communication  (SLOC)  by  preventing  enemy  combatants  from  operating  in  the  area 
[Office  of  the  Chief  of  Naval  Operations.  2007).  Figure  11  is  an  operational  view'  (OV-1) 
depicting  the  interfaces  between  the  various  naval  platforms  involved  in  the  scenario.  The 


activity  diagram  (Figure  12>  focuses  in  on  the  specific  C2  activities  that  arc  performed  by  the  C2 
system  aboard  a  single  ship. 
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Figure  1 1:  Operational  View:  Surface  W  arfare 

This  Operational  View  provides  a  high  level  depiction  of  the  operational  environment  in  winch  the 
SLAV  scenario  it  conducted. 

The  engagement  systems  and  C2  functionality  depicted  tn  Figure  12  arc  organic  to  one 
DDG.  The  Sensor  System  swim  lane  represents  organic  and  nan-organic  sensors.  The 
remaining  DDG  and  FFG  in  die  SAG  serve  as  non-organtc  sensor  platforms  for  the  purposes  of 
this  thread.  A  hostile  combatant  ls  operating  in  the  area.  The  scenario  is  divided  into  live  kill 
chain  phases. 
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Within  the  'Find’Fix*  phase  the  C2  system  defines  the  search  plan  and  promulgates  it  to 
the  Sensor  Systems.  The  search  will  cither  be  directed  or  area  (Office  of  the  Chief  of  Naval 
Operations,  2(K)7).  The  sensors  conduct  the  search  and  find  a  surface  contact. 

The  Sensor  Systems  then  localizes  the  track  and  provides  track  information  to  C2svstcm 
in  the  'FixTrack*  phase.  Using  all  available  information,  the  C2  classifies  the  track  as  a 
combatant  and  reports  tracking  information  to  other  surface  platforms  and  up  the  chain  of 
command,  and  identifies  it  as  hostile  (Office  of  the  Chief  of  Naval  Operations,  2007].  C2 
applies  Rules  of  Kngagcmcnt  ami  decides  to  engage  the  track. 

In  the  'Target'  phase  the  C2  system  considers  sensor  and  weapon  system  information  to 
conduct  targeting.  Targeting  includes  consideration  of  factors  such  as:  desired  effects,  available 
options,  dcconiliction,  weapons  target  pairing,  threat  defense  capabilities  and  environmental 
factors  (Office  of  the  Chief  of  Naval  Operations.  2007J. 

The  C2  system  then  sends  an  engagement  order  to  the  Fngagement  Systems  to  conduct 
the  engagement  dunng  the  'Hngage*  phase.  C2  monitors  the  status  of  the  engagement  via  inputs 
from  the  Sensor  and  Hngagement  Systems. 

Finally  in  the  'Assess*  phase  C2  receives  battle  damage  indicators  from  the  Sensor  and 
Fngagement  Systems  and  performs  a  battle  damage  assessment.  Based  upon  the  battle  damage 
assessment.  C2  will  decide  if  the  target  needs  to  be  reengaged.  If  the  target  does  not  need  to  be 
reengaged,  the  kill  chain  is  complete  and  all  systems  assess  readiness  status. 

c.  Scenario  Exceptions 

There  arc  three  exceptions  associated  with  this  thread.  Hxccptions  arc  "alternative 
endings”  to  the  baseline  scenano.  The  baseline  scenario  describes  one  course  of  decisions  and 
actions.  Exceptions  explore  alternative  actions  and  decisions  that  may  occur  throughout  the 
scenario.  Hxccptions  cannot  address  every  possible  alternative  scenario,  but  they  do  try  to 
capture  common  alternatives  to  the  baseline. 

The  first  exception  is  the  possibility  that  the  target  is  not  to  be  engaged.  C2  decides  not  to 
engage  the  contact  based  upon  parameters  such  as  classification  and  identification  or  ROE*.  The 
kill  chain  is  interrupted,  and  the  action  is  complete.  All  systems  assess  readiness  status.  Surface 
search  is  resumed  based  upon  C2  direction  (Office  of  the  Chief  of  Naval  Operations.  2007|. 
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The  second  exception  is  the  possibility  for  reengagement  of  the  target  due  to  a  positive  track. 
Battle  damage  assessment  indicates  that  the  target  had  not  been  eliminated  [Office  of  the  Chief 
of  Naval  Operations.  2007|.  C2  decides  to  reengage.  C2  still  has  a  positive  target  classification 
and  identification.  C2  applies  ROE  and  engages  the  target  again  in  accordance  with  the  baseline 
description. 

The  third  exception  is  the  possibility  for  reengagement  of  the  target  due  to  a  lost  track.  Battle 
damage  assessment  indicates  that  the  target  had  not  been  killed.  C2  decides  to  reengage.  The 
target  track  is  lost.  C2  identifies  a  search  plan  to  regain  the  target  track(s)  and  conducts  the 
SCW  kill  chain  in  accordance  with  the  baseline  description  (Office  of  the  Chief  of  Naval 
Operations.  2007J.  In  order  to  limit  the  scope  of  the  project  due  to  time  constraints  single 
contacts  were  decided  to  be  the  focus  of  the  SUW  mission  thread. 

4.  Maritime  Interception  Operations 

a .  Overview 

This  thread  particularly  focuses  on  the  use  of  C2  aboard  a  Navy  combatant  platform 
while  performing  Maritime  Interception  Operations  in  a  peacetime  environment.  A  high-level 
depiction  of  the  operational  environment  (OV-l)  is  shown  in  Figure  13.  The  thread  is  divided 
into  five  swim  lanes:  Intelligence.  Surveillance  and  Reconnaissance  Systems;  Maritime 
Intercept  Commander;  Organic  C2:  Organic  Sensors;  and  Boarding  Team.  The  thread  focuses 
on  the  C2  functions,  processes,  and  interfaces  required  to  support  the  mission,  sec  Figure  14.  A 
distinct  difference  between  the  MIO  mission  thread  and  the  SUW  mission  thread  is  the  stronger 
reliance  on  Intelligence.  Surveillance  and  Reconnaissance  (I SR)  assets  and  own  ship  sensor 
assets.  In  the  SUW  thread,  a  wider  variety  of  sensor  resources  arc  available  from  accompanying 
ships.  In  the  MIO  thread,  these  external  sensors  are  not  available. 

b.  Baseline  Description 

Deployed  as  part  of  a  Carrier  Strike  Group  (CSG),  a  DDG  is  operating  independently  to 
conduct  MIO  in  the  Indian  Ocean,  as  shown  in  Figure  13.  The  DDG  has  Condition  III  (wartime 
steaming  with  at  least  half  of  the  systems  at  a  ready  status  at  all  times)  watch  stations  manned. 
The  DDG  has  one  embarked  helicopter  to  support  MIO  and  OTH  search  capabilities.  The  DDG 
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operates  within  the  littorals  and  maneuvers  up  to.  but  not  within.  12  nautical  miles  of  land 
(United  States  Navy.'Umted  States  Marine  Corps/United  States  Coast  (iuard.  2007|.  The  sensor 
systems.  C2  functionality,  and  boarding  team  depicted  are  organic  to  the  DD(i.  The  1SR 
represented  organic  and  non-organic  I  SR  assets. 


Figure  13:  Operational  V  iew:  Maritime  Intercept  Operation 

The  MIO  OY«  I  pmvidet  a  high  loci  depiction  of  ihc  MIO  opcmtucial  envuuninent 


a  MIO  Chain  of  Events 

The  following  sequence  of  events  describes  the  MIO  scenario  and  the  activities  depicted 
in  Figure  l  A.  A  vessel  of  interest  is  operating  in  the  area. 
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Figure  14:  MIO  Mission  Thread 

The  MIO  activily  diagram  depicts  the  event*  that  occur  during  the  MIO  scenario.  The  focus  of 
this  diagram  is  the  Command  and  Control  swim  line,  which  is  used  to  identify  and  tKiund  C2 
functionality. 

ISR  assets  notify  C2  that  a  merchant  vessel  of  interest  is  operating  tn  the  area  | United 
States  Navy/United  States  Coast  Guard,  2003].  C2  defines  the  search  plan  and  promulgates  it  to 
the  sensor  systems.  The  search  is  either  a  directed  search  pattern  or  area  search  pattern  | Office 
of  the  Chief  of  Naval  Operations.  2007]. 

The  sensors  conduct  the  search  and  find  a  surface  contact.  The  sensors  localize  the  track 
and  provide  track  information  to  C2.  Using  all  available  information.  C2  classifies  the  track  as 
the  merchant  vessel  of  interest  and  identifies  it  as  assumed  friendly  (Office  of  the  Chief  of  Naval 
Operations.  2007].  C2  applies  ROE  as  promulgated  by  the  Maritime  Intercept  Commander 
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(MIC),  and  queries  the  merchant  vessel  (United  States  Navy  United  States  Coast  Guard.  2003 J. 
The  DDG  Commanding  Officer  (represented  within  the  Command  and  Control  swim  lane) 
assumes  duties  as  the  On  Scene  Commander  (OSC)  (United  States  Navy, 'United  States  Coast 
Guard,  2003 1. 

After  the  query  is  complete.  C2  passes  the  query  results  to  the  MIC  and  to  the  ISR 
(United  States  Navy/United  States  Coast  Guard.  2003).  The  MIC  evaluates  the  information  and 
authorizes  C2  to  board  the  merchant  vessel. 

C2  directs  the  boarding  party  to  board  the  merchant  vessel  (United  States  Navy/United 
States  Coast  Guard.  2003].  The  boarding  party  provides  status  to  C2  during  the  VBSS  operation 
(United  States  Navy/United  States  Coast  Guard.  2003 (.  C2  compiles  the  VBSS  findings  and 
forwards  the  information  to  ISR  and  MIC.  MIC  evaluates  the  information  and  directs  C2  to 
divert  the  merchant  vessel  (United  States  Navy  United  States  Coast  Guard.  2003 1.  The  scenario 
is  complete  and  all  systems  assess  readiness  status. 

d.  Exceptions 

There  are  three  exceptions  associated  with  this  thread.  All  three  exceptions  result  in  the 
termination  of  the  MIO  action.  The  first  of  these  exceptions  is  the  case  of  a  ‘do  not  query*  order. 
C2  decides  not  to  query  the  merchant  vessel,  based  upon  parameters  such  as  classification  and 
identification  or  ROE!.  The  MIO  action  is  terminated.  All  systems  assess  readiness  status. 
Surface  search  is  resumed  based  upon  C2  direction  (Office  of  the  Chief  of  Naval  Operations. 
2007 1. 

The  second  exception  is  the  event  of  a  *I)o  not  board*  order.  MIC  docs  not  authorize 
boarding  of  the  merchant  vessel,  based  upon  parameters  such  as  results  of  the  query  or  ISR 
information.  The  MIO  action  is  terminated.  All  systems  assess  readiness  status.  Surface  search 
is  resumed  based  upon  C2  direction  (Office  of  the  Chief  of  Naval  Operations.  2007 1. 

The  third  exception  is  the  event  of  a  ‘Do  not  divert*  order.  MIC  docs  not  authorize  boarding 
the  merchant  vessel,  based  upon  parameters  such  as  results  of  the  VBSS  or  ISR  information. 
The  MIO  action  is  terminated.  All  systems  assess  readiness  status.  Surface  search  resumes  based 
upon  C2  direction  (Office  of  the  Chief  of  Naval  Operations.  2007]. 
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5.  Mission  Thread  Analysis  Conclusions 

The  mission  thread  analysis  produced  two  viable  representative  mission  threads  from  the 
analysis  of  doctrinal  requirements  represented  in  the  stakeholder  analysis.  The  mission  threads 
were  a  result  of  analyzing  how  the  project  proposal  and  problem  statement  could  be  represented 
to  meet  doctrine  needs  identified  in  the  stakeholder  analysis.  In  addition,  the  mission  threads 
analysis  scoped  and  bounded  the  project  proposal  to  a  manageable  level  to  help  by  focusing 
system  functionality.  The  mission  threads  also  depicted  the  operating  environment-situation 
(OV-l's) and  the  process  How  to  be  used,  as  seen  in  Figure  14.  Additionally,  the  mission  threads 
facilitated  the  generation  of  the  C2  requirements,  which  are  addressed  in  the  requirements 
definition  section  of  this  report. 

C.  THREAT  ANALYSIS 

1.  Background 

The  threat  analysis  explored  current  and  future  threats  to  U.S.  Navy  platforms  and  their 
capabilities  as  background  for  the  requirements  definition  and  mission  thread  definition  tasks. 
These  threats  and  their  capabilities  were  identified  during  the  Stakeholder  Analysis. 
Charactcri sties  of  the  threats  were  used  to  support  key  C2  requirements,  such  as  the  requirement 
to  integrate  off-board  sensors  into  the  track  picture.  Thus,  while  the  threat  assessment  did  not 
define  specific  requirements,  it  provided  information  that  was  used  to  develop  the  C2  system 
requirements. 

The  “Navy  Surface  Warfare  Manual,"  NWP  3-20,  defines  the  categories  of  threats 
against  IJ.S.  naval  platforms  | Office  of  the  Chief  of  Naval  Operations,  2007].  Threats  have 
evolved  from  conventional  threats  of  surface  combatants,  submarines,  and  coastal  defenses  to  a 
wide  array  of  unconventional  threats.  These  unconventional  threats  include  FAC  or  patrol  craft, 
small  aircraft.  UAVs.  small  submcrsiblcs.  commercial  platforms,  piracy  and  crime,  directed 
energy,  cyber  attacks,  and  WMDs  (Office  of  the  Chief  of  Naval  Operations.  2007 1. 

The  threats  against  U.S.  Navy  ships  have  not  remained  constant.  The  geographic  location 
of  threats  is  changing  from  the  blue  water  to  littoral  conflicts.  Combined  with  the  location,  the 
threat  has  evolved  from  major  naval  adversaries  to  regional  or  coastal  navies  and  non-state  actors 
(United  States  Navy/United  States  Marine  Corps.  2006]. 
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Threats  from  other  conventional  navies  cannot  be  excluded  from  analysis.  China 
possesses  a  large  number  of  guided  missile  boats,  frigates,  destroyers  and  submarines  as  well  as 
a  single  aircraft  carrier  (Global  Security.org,  "Chinese  Warships.”  2008].  Other  significant 
navies  exist*  particularly  India  and  Russia.  India  has  multiple  aircraft  carriers  and  a  large 
number  of  frigates,  destroyer,  corvettes*  patrol  craft,  and  submarines  (Global  Sccurity.org* 
'‘Indian  Navy,”  2008].  While  declining  in  size,  the  Russian  Navy  still  possess  submarines, 
destroyers,  frigates,  corvettes  and  patrol  craft  (Global  Security.org.  “Russian  Warships*”  2008]. 
Emerging  conventional  threats  include  small  torpedo  and  ASCM  boats  (Stockbauer*  2008).  To 
maintain  a  manageable  scope*  the  focus  of  the  conventional  threat  assessment  was  maintained  on 
China's  Navy,  whose  platforms  arc  representative  of  the  types  of  threats  from  a  conventional 
navy. 

The  combination  of  insurgent  and  non-state  actors  using  non-convcntional  weapons  and 
conventional  threats  from  other  state  nav  ies  poses  a  complex  threat  to  U.S.  Navy  platforms.  The 
conventional  and  unconventional  threat  sections  detail  some  of  the  specific  threat  types  that  must 
be  addressed  in  ship  combat  system  requirements. 

2.  Methodology 

The  threat  assessment  was  conducted  by  surveying  available  public  intelligence  sources. 
This  assessment  was  constrained  to  an  unclassified  level*  and  only  open  source  intelligence  was 
used.  Sources  included  congressional  testimony,  third  party  information  sources  such  as 
CilobalSccunty.org*  and  public  reports  from  the  DoD  and  the  United  Nations. 

The  threat  categories  were  taken  directly  from  NWP  3-20*  the  “Navy  Surface  Warfare 
Manual”  (NSWM).  The  NSWM  addresses  all  missions  performed  by  U.S.  Navy  surface 
combatants*  however,  the  mission  threads  were  focused  on  the  detection,  tracking,  classification, 
identification,  reporting,  and  engagement  or  boarding  of  surface  contacts.  Thus*  the  threat 
assessment  was  limited  to  surface  platforms,  specifically,  surface  combatants.  FAC,  and 
commercial  platforms,  whose  onboard  systems  and  payloads  could  be  used  to  threaten  U.S.  Navy 
ships. 
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3.  Geographic  Threat  Regions 

Just  as  the  threats  have  expanded,  so  has  the  geographic  focus  of  U.S.  Navy  operations. 
The  U.S.  Navy  has  broadened  from  blue-water,  major  ocean  conflict  with  established  navies  to 
littoral  conflicts  with  non-state  actors.  The  emerging  regions  include  Africa,  South  America  and 
the  Straits  of  Malacca  [United  States  Navy/United  States  Marine  Corps.  2006].  Hotspots  in 
recent  years  include: 

•  Nigeria  (Niger  Delta):  An  unstable  and  impoverished  region  characterized  by 
ethnic  clashes,  commercial  sabotage,  significant  oil  resources  with  little  distribution 
of  wealth,  environmental  damage,  chronic  poverty,  and  limited  economic 
opportunities  [Globa!  Security.org,  "Nigeria  -  Niger  Delta."  2008]. 

•  C  olombia:  A  38-year  civil  war  involving  two  leftist  insurgent  groups  and  a  right- 
wing  paramilitary  organization,  focused  in  the  eastern  lowlands  and  southern 
rainforest.  The  leftist  and  right-wing  groups  have  allied  with  drug  trafficking 
organizations  and  conducted  numerous  kidnappings  to  fund  the  insurgency  [Global 
Sccunty.org.  "Colombia  -  Insurgency,"  2008 1. 

•  Somalia:  No  national  government  exists  and  fighting  between  clans  and  factions  is 
violent  and  flares  up  quickly,  especially  in  the  south.  IJ.S.  and  United  Nations 
peacekeeping  missions  led  to  significant  casualties  and  were  withdrawn  in  the  mid- 
1990s  [Cilobal  Security.org,  "Somalia  Civil  War.”  2008 1.  Piracy  is  also  common  in 
the  area  and  will  be  addressed  in  detail  later  in  the  document. 

•  Indonesia  (Aceh):  An  Islamic  separatist  movement  has  been  fighting  for  an 
independent  state  since  the  1970s.  The  Indonesian  military'  has  occupied  the  area 
since  1991.  with  substantial  violence  on  both  sides  [Cilobal  Secunty.org.  "Free  Aceh 
(Aceh  Merdcka),"  2008]. 

4.  Conventional  Threats:  Surface  C  ombatants 

The  Chinese  People's  Liberation  Army  Navy  (PLAN)  surface  combatant  fleet  in  2007 
consisted  of  some  27  destroyers  and  47  frigates,  plus  a  large  number  of  guided  missile  boats, 
torpedo  boats  and  patrol  boats.  Chinese  destroyers  fall  into  seven  classes,  listed  from  oldest  to 
newest:  Luda.  Luhu.  Lihai.  Luyang.  Luyang  II.  Hangzhou  and  Luzhou.  The  Luda  represents  the 
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bulk  of  the  current  Chinese  destroyer  licet.  However,  it  is  being  phased  out  in  favor  of  the 
Luyang  II.  Hangzhou  ami  Luzhou-class  destroyers  (Global  Sccunty.org.  "Chinese  Warships/* 
2008]. 

The  threat  assessment  was  focused  on  Hangzhou  and  Luzhou  class  destroyers,  the  two 
newest  classes  of  destroyers.  The  Hangzhou  class,  pictured  in  Figure  15.  is  of  interest  because 
the  Hangzhou  class  destroyers  arc  Sovrcmenny-class  destroyers  purchased  from  the  Russians. 
The  Russian  Sovrcmenny-class  destroyers  arc  considered  to  represent  a  more  capable  and 
balanced  design  than  other  Chinese  warships.  The  Sovrcmenny-class  destroyers  carry  the  Top 
Plate  D/E-band  air  search  radar  and  the  Palm  Frond  I-band  surface  search  radar  (Global 
Sccurity.org.  "Hangzhou  Type  956  Specifications.**  2008 1.  The  Sovrcmenny-class  destroyers  arc 
equipped  with  SA-N-7  ’•Gadfly"  or  SA-N-17  ’’Grizzly"  surfacc-to-air  missiles  (SAM).  Both 
missiles  arc  considered  intermediate-range,  with  a  range  of  25  km  (Global  Sccurity.org. 
"Hangzhou  Type  956.**  2008].  Of  more  importance  is  that  the  Sovrcmenny-class  destroyers 
carry'  the  SS-N-22  Sunburn  surface-to-surface  missile.  The  Sunburn  is  a  sea-skimming  missile 
with  a  range  of  161  km.  a  speed  up  to  4.5  mach  and  an  active  and  passive  radar  seeker  (Global 
Sccurity.org.  "Hangzhou  Type  956  Specifications.*'  2008| 
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Figure  15:  Klai/hou  Type  956  Destroyer 

Ifang/hou  Type  956  destroyers  are  a  surface  threat  interest.  They  arc  Russian  Sovremenny  claw 
destroyers  capable  of  carrying  the  SS-N-22  surface- to -surface  missile.  (From  (ilohalSecurity.org. 
“Hai/hctu  Type  956  Pictures,"  2008) 

The  Luzhou  class  is  the  newest  Chinese  destroyer.  The  Luzhou  class  is  designed 
primarily  for  anti-air  warfare.  Little  technical  data  is  publically  available  on  this  ship  class. 
However,  for  the  purposes  of  this  threat  assessment,  it  is  considered  less  of  a  threat  than  the 
Hangzhou  class  described  above  [Global  Security.org.  ‘Type  5 1C  Luzhou  DDG-X,"  2008 1. 

Chinese  frigates  consist  of  four  classes,  listed  from  oldest  to  newest:  Jianghu.  Jiangwei  I. 
Jiang wei  II  and  Jiangkai.  The  Jianghu  class  is  being  phased  out  of  the  Chinese  licet  with  the 
new'  frigate  construction  focusing  on  the  Jiangkai  class,  constituting  all  new  frigate  production 
(Global  Sceunty.org.  •‘Chinese  Warships,"  2008). 

The  Jiankai  class  will  possess  a  limited  anti-air  warfare  and  surface  warfare  capability. 
With  the  addition  of  Russian  Kamov  Ka-28  anti-submarine  warfare  helicopters  and  an  active  and 
passive  sonar  system,  the  mission  of  the  class  is  primarily  anti-submanne  warfare.  As  a  surface 
threat,  the  Jiankai  class  design  uses  stealth  shaping,  comparable  to  the  French  Lafayette-class 
frigates  [Global  Sccurity.org.  “Jiangkai  Type  054  Frigate,"  2008]. 
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The  threat  to  U.S.  naval  platforms  is  not  limited  to  destroyers  and  frigates.  The  Houxin 
guided  missile  boats,  w  hich  constitute  the  largest  segment  of  China's  missile  boat  fleet,  carry*  the 
YJ-1  surface-to-surface  missile  |GlobalSccurity.org.  “Houxin  Class  (Type  037-1(1  /  Type  343M) 
large  missile  boats,"  2008).  The  YJ-1.  also  known  as  the  C-801.  is  believed  to  be  the  result  of 
revcn>e  engineering  of  the  Exocct  missile.  The  missile  has  been  demonstrated  in  tests  to  be  able 
to  sink  a  ship  of  10,000  ton  displacement  and  has  a  maximum  effective  range  of  42  kilometers 
IGlobalSccurity.org,  “C-801  YJ-1  /  YJ-8  (Eagle  Strike)  /  YJ-83  /  CSS-N-4  SARDINE,"  2008). 

5.  Unconventional  Threats 
a.  Fast  A ttack  Craft 

Of  major  focus  in  the  category  of  unconventional  threats  arc  small  boats.  These  cratl  can 
travel  up  to  40-50  knots,  are  armed  with  50  caliber  machine  guns  and  Rocket  Propelled  Grenades 
(RPG)  and  possibly  more  advanced  weapons,  are  manned  by  a  crew  of  2-3  or  higher  depending 
on  size  and  have  a  low  RCS  [Haas  and  Neel.  2008).  Small  boats  can  be  divided  into  two 
categories:  FAC  and  Fast  Inshore  Attack  (  rail  (FI AC). 

FAC  arc  small  military  vessels  used  by  countries  with  established  navies  for  patrol, 
enforcement,  search  and  rescue  and  coastal  defense.  They  are  fast,  maneuverable,  capable  of 
operating  in  relatively  shallow  waters,  have  a  relatively  small  radar  signature  and  can  cany  a 
variety  of  lethal  anti-ship  armament.  They  arc  used  by  countries  with  large  navies  and  extensive 
coastline  as  well  as  smaller  countries  with  negligible  other  naval  assets  (Office  of  the  Chief  of 
Naval  Operations.  2007).  Examples  shown  in  Figure  16  and  Figure  17  include  the  Super  Dvora 
and  Roussen  Class  FAC's  and  provide  a  sense  of  the  size  and  maneuverability  of  the  FAC-type 
vessels. 
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Figure  16:  Super  Dvora  Fast  Attack  Craft 


The  Super  Dvora  FAC  it  a  small,  highly  maneuverable  vessel  well  suited  for  operating  in  the 
littorals  [From  Office  of  the  Chief  of  Naval  Operations.  2007 1. 


Figure  17:  Koussen  Class  Fast  Attack  Missile  Craft 


The  Rouxsen  Clast  is  another  example  of  a  FAC :  highly  effective  in  the  littorak  (Naval 
Technology  .com). 


FIAC  arc  militarized  commercial  boats  that  arc  capable  of  limited  operations  in  near¬ 
shore  coastal  areas.  As  the  nautical  equivalent  of  "technicals**  (pickup  tmeks  with  machine  gun 
mounts  used  ashore  in  many  third  world  nations),  these  vessels  are  small-signature,  fast, 
economical,  and  can  be  pressed  into  service  on  short  notice  in  large  numbers.  FIAC  size  can  be 
as  small  as  a  personal  watercraft,  can  be  open  or  enclosed,  and  have  a  small  crew.  These  craft 
arc  often  capable  of  operating  at  speeds  over  30  knots.  FIAC  have  limited  sensors,  weapons. 
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payload,  and  fuel.  FIACs  arc  hard  to  detect  because  they  blend  with  the  coastal  environment  and 
it  is  difficult  to  ascertain  their  intentions.  They  arc  usually  unarmored  and  depend  on  speed  and 
surprise.  When  used  in  a  mass  attack,  the  time  to  detect  and  identify  a  FIAC  as  hostile  can 
permit  enough  time  for  the  FIAC  to  get  close  and  overwhelm  a  combatant's  defenses  [Office  of 
the  Chief  of  Naval  Operations.  2007).  Figure  IS  provides  an  example  of  an  alleged  Iranian 
FIAC,  illustrating  both  the  size  and  manning  of  the  vessel. 


Figure  18:  Alleged  Iranian  FIAC 

Thu  alleged  Iranian  FIAC  was  filmed  by  the  USS  Hopper  in  the  Strait  of  Hormuz,  6  Jan  2008.  It 
appear\  lo  k  j  pleasure  craft  type  vessel  that  k  being  used  for  military  purposes  (Karl  and 
Martinez.  2008]. 

FAC  and  FIAC  are  well  suited  for  coastal  defense  where  the  crew*  know  the  waters  well 
and  can  take  advantage  of  shallows  and  concealment  areas  to  launch  short-notice  surprise  attacks 
against  hostile  naval  units.  In  this  role  they  can  take  advantage  of  inlets  and  coastal  clutter  for 
concealment,  and  shore-based  Command,  Control  and  Communications  (C3)  and  ISR  networks 
for  support  and  coordination  (Office  of  the  Chief  of  Naval  Operations.  2007:  Haas  and  Neel. 
2008). 

Defense  against  FAC  and  FIAC  depends  largely  on  an  understanding  of  the  threat, 
potential  threat  tactics,  and  own-force  readiness.  FAC  arc  armed  with  a  variety  of  conventional 
naval  weapons  including  crew  served  and  automatic  naval  canon  and  machine  guns,  surfacc-to- 
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surface  missiles  (SSM)  and  SAMs,  torpedoes.  RPGs  and  small  arms  (Office  of  the  Chief  of 
Naval  Operations.  2007). 

One  of  the  most  common  RPGs  is  the  Russian-made  RPG-7,  which  has  a  maximum 
effective  range  of  500  meters  for  stationary  targets  and  300  meters  for  moving  targets 
(GlobalSecurity.org,  "RPG-7/’  2008).  However,  the  use  of  a  RPG  from  a  moving  platform 
makes  effective  use  difficult  (Haas  and  Neel.  2008).  A  0.50-caliber  machine  gun  has  a  longer 
effective  range,  up  to  1.830  meters  for  the  U.S.  M2  "Ma  Ducc"  | (ilobalSccurity.org.  "M2  .50 
Caliber  Machine  Gun.*’  2008).  However,  employment  from  a  moving  ship  will  still  require 
stabilization  to  be  effective  |  Haas  and  Neel.  2008). 

FI  AC  may  be  aimed  with  a  variety  of  weapons,  from  small  arms  and  rocket  propelled 
grenades,  to  anti-tank  missiles  and  rccoillcss  ritles.  They  can  also  be  filled  with  explosives  and 
used  as  waterborne  lEDs  cither  by  remote  control  or  with  suicide  crew  (Office  of  the  Chief  of 
Naval  Operations.  2007).  A  platform  smaller  than  a  FI  AC  can  also  be  employed  as  a  Remotely 
Operated  Vehicle  (ROV).  The  ROV  threat  could  include  platforms  as  small  as  a  jet  ski  (Haas  and 
Neel.  200KJ. 

It  is  important  to  note  that  the  goal  of  an  unconventional  attack  is  not  necessarily  to  sink 
the  platform.  One  goal  that  can  impact  overall  force  effectiveness  is  to  cause  sufficient  damage 
to  reduce  a  ship’s  operational  capability.  This  will  force  the  ship  to  remove  itself  from  battle, 
likely  while  drawing  protection  from  another  friendly  platform(s).  For  example  the  ship’s  radar 
arrays  may  be  targeted  specifically  to  reduce  operational  capability  (Haas  and  Neel.  2008). 

b.  Commercial  Platforms 

Commercial  ships  sen  e  a  wide  variety  of  purposes  and  thus  vary  greatly  in  size  and  form 
from  extremely  large  commercial  carriers  to  small  size  fishing  vessels.  Commercial  ships  can 
pose  a  risk  to  U.S.  Navy  ships  if  used  as  an  unconventional  attack  platform.  The  use  of  a 
legitimate  commercial  ship  for  an  attack  will  make  positive  identification  challenging  prior  to  the 
moment  of  attack. 

Lloyd’s  Register  classifies  ships  into  the  following  categories:  bulk  carriers,  container, 
cruise,  gas.  naval,  ropax.  tanker  and  yacht  (Lloyd’s  Register.  "Marine  Ship  Types.’’  2008).  This 
analysis  was  focused  on  bulk  carrier,  tanker,  container,  and  gas  ships,  as  well  as  fishing  vessels. 
Other  types  not  discussed  include  tug.  barge,  and  roll-onTol  1-off  ships. 


Tanker  and  bulk  carrier  ships  represent  the  largest  portion  of  commercial  deadweight 
tonnage,  accounting  for  36.9%  and  36.0%  respectively,  of  total  commercial  deadweight  tonnage 
in  2006  (United  Nations  Conference  on  Trade  and  Development,  2006).  Tanker  ships  are 
designed  to  carry  crude  or  refined  oil  products.  Tanker  ships  range  in  capacity  from  10.0CK)  to 
550,000  deadweight  tons  (dwl),  divided  into  the  types  seen  in  Table  6  (Global  Sccurity.org. 
•Tanker  Types”  2008). 


I  ablc  6:  C  ommercial  Platform  Sizes 

These  common  commercial  vessels  have  large  cargo  capacities  and  can  be  used  »  unconventional 
threats  to  natal  combatant  ships. 


landymax 


Panamax 


Aframax 


Ultra  Large  Crude  Carrier 
(ULCC) 


10.000  -  30,000 


30.001  -  50.000 


50.001  -  80.000 

(constrained  by  the  locks  of  the  Panama  Canal) 


80.001  -  1 19,000 


up  to  150.000 

(constrained  by  the  Suez  Canal) 


over  150.000 

(must  travel  around  Cape  Mom  or  the  Cape  of  Good  Hope) 


Aker  Philadelphia  Shipyard  builds  the  Veteran  Class  MT46,  a  tanker  ship  with  a  length 
of  183  meters,  a  drat)  of  12.2  meters,  a  deadweight  tonnage  of  45.800  tons,  a  speed  of  14.6 
knots,  a  range  of  14.000  nautical  miles  and  a  crew  capacity  of  32  (Aker  Philadelphia  Shipyard. 
•Veteran  Class  MT46  Product  Tankers  Data  Sheet.”  2008). 

Bulk  carriers  arc  designed  to  carry  powders  and  grains  that  arc  stored  in  loose  form. 
Cargo  includes  cement,  grains  and  salt.  Bulk  carriers  follow  a  similar  type  structure  as  tanken> 
(Global  Sccunty.org.  "Bulk  Cargo  Carrier  ”  2008). 

Container  ships  continue  to  grow  in  size  and  quantity,  growing  in  total  deadweight 
tonnage  by  13.3  percent  in  2006.  The  average  capacity  of  container  ships  was  2,324  twenty-foot 
equivalent  units  (TEUs)  in  2006.  However,  new  classes  of  container  ships  have  capacities  of 
over  9.000  TEUs  with  Macrsk  Line  producing  a  mega  ship  with  a  capacity  of  13.640  TEIJ 
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(United  Nations  Conference  on  Trade  and  Development,  2006).  One  specific  example,  Aker 
Philadelphia  Shipyard  produces  the  Philadelphia  CV2600  class  container  ship,  with  a  length  of 
217  meters,  a  draft  of  12.5  meters,  a  deadweight  tonnage  of  29,400  tons,  a  speed  of  22.5  knots,  a 
range  of  over  10.0(H)  nautical  miles  and  a  crew  capacity  of  26  [Aker  Philadelphia  Shipyard. 
“Philadelphia  CV2600  Containership  Data  Sheet;*  2008). 

Liquid  Natural  Gas  (LNG)  tankers  are  typically  259  meters  in  length  and  carry  120.000 
cubic  meters  of  LNG.  Natural  gas  is  liquefied  at  minus  160  degrees  Celsius  and  is  stored  in 
insulated  tanks  on  the  ship  (Global  Sccurity.org.  ’Tanker  Types,**  2008).  The  effects  of  a  LNG 
explosion  arc  not  well  known.  Industry  officials  claim  that  any  explosion  would  be  confined  to 
the  tanker.  However,  the  potential  exists  for  clouds  of  natural  gas  to  escape  and  lead  to  “back 
burn,**  or  gas  cloud  fires  well  away  from  the  LNG  ship  |  Daniel.  2004). 

Fishing  vessels  vary  greatly  depending  upon  the  location.  In  Somalia,  illegal  fishing  is 
rampant  due  to  the  lack  of  government  enforcement.  Fishing  vessels  from  a  variety  of  countries, 
Belize.  France.  Honduras.  Japan.  Kenya.  Korea.  Pakistan.  Saudi  Arabia.  Spain.  Sri  Lanka. 

Taiwan  and  Yemen,  work  off  the  coast  of  Somalia. 

c  Criminal  and  Piracy  Organizations 

Maritime  piracy  consists  of  any  '‘illegal  act  of  violence  or  detention  committed  for 
private  ends  against  a  ship,  aircraft,  or  persons  or  property  on  board**  a  ship  or  aircraft 
'‘committed  on  the  high  seas**  (Amcri  and  Shcwchuk.  2()08:  9).  Although  the  United  Nations 
Convention  on  the  Law  of  the  Sea  of  1982  distinguishes  legally  between  piracy  and  robbery  at 
sea.  the  two  commonly  arc  joined  and  many  sources,  including  this  summary,  consider  armed 
robbery  at  sea  as  one  form  of  piracy  (Amcri  and  Shcwchuk.  2008). 

Modern  maritime  piracy  is  an  increasing  threat  to  merchant  and  private  vessels  transiting 
or  visiting  certain  regions  of  the  world.  Areas  with  widespread  or  severe  poverty,  failed 
governments  and  inadequate  lawr  enforcement  have  seen  sharp  increases  in  the  number  of 
reported  incidents.  Criminals  in  some  areas  have  learned  that  it  is  possible  to  gain  large  rewards 
by  robbing  or  ransoming  undefended  transient  mariners.  Governmental  ineffectiveness  or  even 
complicity  has  propagated  the  trend.  The  International  Maritime  Bureau  Piracy  Reporting 
Center  has  reported  "an  unprecedented  increase**  in  pirate  activity  for  the  first  three  quarters  of 
2008.  with  a  total  of  199  incidents.  These  incidents  include  115  vessels  boarded.  31  hijacked 
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and  23  fired  upon.  Five  hundred  eighty-one  crewmembers  were  taken  hostage,  nine  kidnapped, 
nine  killed  and  seven  missing  and  presumed  dead.  Almost  a  third  of  the  incidents  occurred  in  the 
waters  near  Somalia,  with  12  vessels  and  250  crew  still  held  captive  as  of  30  September  2008. 
Nigeria  was  second  in  terms  of  numbers  of  reported  incidents  (24),  mostly  in  the  Lagos  region, 
but  a  significant  percentage  of  Nigerian  incidents  go  unreported.  Indonesia  ranked  third  in 
numbers  of  attacks  (23).  Both  Indonesia  and  the  formerly  hot  Malacca  Straits  have  both  seen 
piracy  decrease  recently.  Other  persistent  regions  of  activity  include  the  Indian  Ocean.  Southeast 
Asia,  and  South  America  (ICC-Commcrcial  Crime  Serv  ices.  2008). 

Other  forms  of  criminal  activ  ity  pose  less  of  a  threat  to  naval  forces  but  still  impact  the 
course  of  United  States  naval  operations.  Sanction  enforcement,  counter-proliferation  activities, 
protection  of  human  rights  (trafficking  in  persons),  anti-drug  operations,  and  counter-terrorist 
patrols  each  bring  Navy  personnel  in  contact  with  hostile  forces  with  incentive  and  potential 
means  to  resist  forcefully. 

The  modus  operandi  of  pirate  attacks  includes  covert  boarding  of  anchored  vessels  at 
night,  or  pursuit  in  small  boats  and  boarding  with  grappling  hooks  and  ladders  by  day.  Weapons 
can  range  from  knives  and  machetes  to  military  small  arms  and  RPGs.  A  typical  scenario  alter 
boarding  includes  robbing  the  crew  and  stripping  the  vessel  of  anything  of  value  and.  particularly 
around  Somalia,  kidnapping  the  crew',  ship  and  cargo  for  ransom.  Vessels  attacked  range  from 
small  private  yachts  to  large  container  ships  and  bulk  cargo  carriers.  Most  pursuit  attacks  occur 
in  daylight  and  at  speeds  averaging  about  15  knots  (Office  of  Naval  Intelligence.  2008). 

The  threat  to  naval  vessels  is  minimal  when  the  pirates  arc  unchallenged,  but  during 
enforcement  activities  the  intercepting  vessel  can  expect  to  be  fired  upon.  On  March  18.  2006 
the  USS  Cape  St.  George's  (CG  71)  topsides  sustained  light  damage  from  small  amis  fire  while 
performing  maritime  security  operations  in  international  waters  off  the  coast  of  Somalia.  USS 
Gonzalez  (DDG  66)  and  Cape  St.  George  spotted  and  prepared  to  board  a  suspicious  vessel 
towing  two  skiffs,  when  the  suspected  pirates  opened  tire  with  small  amis.  The  Navy  ships 
returned  lire  killing  one  suspect,  burning  the  vessel  to  the  waterline,  and  capturing  the  twelve 
surviving  suspects  (United  States  Naval  Forces  Central  Command  (NAVCENT)  Public  Affairs. 
2008]. 

Threats  expected  from  other  forms  of  criminal  activities,  if  any.  would  most  likely  be 
some  form  of  resistance  against  boarding  panics  using  individual  weapons.  However. 
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interdiction  of  a  terrorist  activity  could  result  in  a  suicide  ramming  attempt  or  use  of  their  vessel 
as  a  maritime  delivered  IED  (Office  of  the  Chief  of  Naval  Operations.  2007|. 

6.  Threat  Signatures 

From  the  stakeholder  analysis,  a  user  need  was  identified  to  be  able  to  classify  and 
identify  tracks  using  all  available  sensor  sources.  The  possible  threat  signatures  that  can  he  used 
by  the  C2  system  in  support  of  classification  and  identification  include  radar.  EO/IR.  electronic 
support  (ES)  and  acoustic.  Each  threat  type  will  have  the  potential  to  have  signatures  that  can  be 
detected  by  the  above  sensor  sources. 

Radar  Cross  Section  (RCS)  data  vanes  based  on  azimuth,  radar  frequency  and  Swcrling 
case,  but  can  be  roughly  quantified  for  the  threats  addressed  above.  The  RCS  for  a  small  boat  or 
FI  AC  will  be  on  the  order  of  0.02  m:  |  Payne,  2006).  One  can  reasonably  expect  that  the  RCS  for 
a  smaller  size  ROV  will  be  even  smaller.  For  surface  combatants,  including  the  guided  missile 
boat  and  destroyer  threats  and  commercial  ships,  the  RCS  is  approximately  equal  to  the 
displacement  tonnage  expressed  in  m*  (Payne.  2006).  For  the  Haizhou  class  destroyer,  the  RCS 
is  approximately  7.500  m\  For  the  Houxin  class  guided  missile  boat,  the  RCS  is  approximately 
500  m2  [Payne.  2006). 

The  HO.  IR.  ES  and  acoustic  signatures  of  different  ships  arc  unique  and  can  only  be 
discussed  generally  in  this  assessment.  HO  detection  is  a  function  of  the  environment  and  is 
based  on  the  amount  of  visual  contrast.  The  IR  signature  of  a  ship  is  driven  by  the  exhaust  points 
and  the  temperature  contrast  of  the  ship’s  exterior  surfaces  with  its  background,  both  of  which 
arc  thermal  sources.  The  HS  signature  of  a  ship  is  driven  by  the  ship’s  RF  emitters,  including 
navigation  radar,  and  communications  systems.  The  acoustic  signature  of  a  ship  consists  of  a 
mix  of  narrowband  and  broadband  sources.  Machinery'  is  the  primary  narrowband  acoustic 
source  for  a  ship.  Flow  and  cavitations  are  broadband  acoustic  sources  and  arc  a  function  of  the 
ship’s  speed  [Payne.  2006). 


48 


7.  Threat  Assessment  Conclusions 


The  threat  assessment  reviewed  an  array  of  threats,  ranging  from  the  FAC  and  FI  AC 
threats  to  conventional  naval  combatants  and  commercial  vessels.  The  threats  facing  U.S.  Navy 
platforms  include  a  wide  range  of  threat  sizes,  speeds,  threat  systems  capabilities  and 
employment  techniques. 

The  threat  assessment  identified  five  major  types  of  threats  from  the  above  mentioned 
threat  categories:  ROV,  small  boats  and  FI  AC,  guided  missile  boats,  destroyers  and  commercial 
vessels.  The  ROV  threat  is  specifically  treated  as  an  I  ED.  The  small  boat  threat  would  be 
crewed  and  used  in  a  coordinated,  massed  attack.  Both  threats  present  the  same  challenge  of 
employment  in  constrained  areas  where  the  threat  can  use  the  environment  and  local  ship  traffic 
to  screen  intentions  (Haas  and  Neel.  2008).  Commercial  vessels  present  a  threat  primarily  when 
they  arc  utilized  as  a  platfomi  for  attack  or  as  an  IED,  similar  to  the  ROV  or  FIAC  threat  but  on  a 
much  larger  scale  (Office  of  the  Chief  of  Naval  Operations.  2007). 

Conventional  threats  present  similar  challenges  in  that  they  can  range  greatly  in  size, 
from  guided  missile  boats  to  destroyer-size  platforms.  However,  the  threat  systems  with  the 
greatest  range  continue  to  be  the  ASCM,  which  will  range  in  capability  up  to  160  kilometers 
(Global  Secunty.org.  "Hangzhou  Type  956  Specifications,"  2008). 

Table  7  summarizes  some  of  the  key  characteristics  of  those  threats  and  some  of  the 
specific  challenges  associated  w  ith  the  management  of  those  threats. 
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Tabic  7:  Summary  of  Threat  Parameters 

This  table  contains  a  vumrmry  of  the  threats  and  their  related  characteristics  identified  during  the 
Threat  Analysis. 


ROV 

Comparable  to 
jet-ski 

40-50  kts 

1ED 

Low  RCS  :  Blend  in 
environment 

Small  Boat  & 
MAC 

Comparable  to 

recreational 

watercraft 

40-50  kts 

KPG:  300-500  m 
50  cal:  1.830  m 

Massed  attack;  Low 
RC’S;  Blend  in 
environment 

Guided  Missile 
Boat  (PLAN 
Houxin  class) 

62  nt  length 

7.2  m  beam 

32  kts 

YJ-l/C-801:  42 

km 

Small;  extended 
range  threat 

Destroyer 
(PLAN  Haizhou 
class) 

156.4  m  length 

1 7.2  meters 
beam 

32  kts 

SS-N-22 

Sunburn:  161  km 

Multi-mission 
surface  combatant 

Commercial 

Vessel 

Can  be  over 

200  m 

15-25  kts 

RPG.  50  cal.  IED 

Difficult  to  identify 

The  information  gathered  during  the  threat  assessment,  including  threat  types, 
signatures,  speeds,  weapon  systems  and  ranges,  have  some  applicability  to  the  definition  of  the 
C2  system  requirements.  The  threat  information  summarized  in  Table  7  provided  inputs  to 
requirements  development,  which  will  be  discussed  in  Section  III.  A.  of  this  report.  However,  the 
specific  threats  and  their  parameters  have  more  applicability  to  the  definition  of  sensor  and 
weapon  system  requirements  for  naval  platforms.  For  example,  the  RCS  of  a  personal  watercraft 
does  not  affect  the  C2  system's  required  performance.  The  personal  watercraft's  RCS  is  of 
substantial  import  to  the  definition  of  sensor  system  requirements,  which  arc  outside  the  scope  of 
this  effort. 

The  threat  assessment  reinforces  some  key  stakeholder  requirements,  including  the  need 
to  integrate  oft-board  sensors  (Haas  and  Neel.  2008)  and  to  utilize  all  available  sensor  data  [Haas 
and  Neel.  2008).  The  over-the-horizon  engagement  ranges  for  enemy  missile  systems,  such  as 
the  SS-N-22  and  the  YJ-1,  highlight  the  need  to  utilize  off-board  sensors  to  extend  the  ship's 
detection  range.  The  small  RC’S  for  Fl.AC  and  FAC  vessels  underline  the  need  to  exploit  all 
available  sensors  to  detect,  classify,  and  identity  the  vessels  as  detections  solely  off  radar  data 
alone  will  be  challenged  by  the  small  RCS. 
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III.  FUNCTIONAL  ANALYSIS 


Requirements  and  architecture  products  were  produced  in  the  Functional  Analysis  phase. 
Using  the  information  gathered  during  the  Needs  Analysis  phase,  the  value  system  design  and 
requirements  definition  tasks  developed  the  system  requirements.  The  enterprise  architecture 
then  modeled  the  system  functionality  required  to  satisfy  the  requirements.  Through  this  phase, 
previous  tasks  were  revisited  to  determine  if  stakeholder  inputs  were  needed  for  clarification,  if 
mission  threads  were  adequately  defined,  and  if  the  threat  assessment  was  fully  established. 

A.  REQUIREMENTS  DEFINITION 

1.  Background 

The  requirements  definition  task  sought  to  translate  stakeholder  needs  and  objectives  from 
the  Needs  Analysis  phase  into  functional  requirements  descriptive  of  a  C2  activity,  and  to 
allocate  these  requirements  into  a  functional  architecture  capable  of  performing  that  activity. 
When  possible,  realistic  or  plausible  operational  constraints,  measures  of  effectiveness,  and 
measures  of  performance  thresholds  were  identified  and  associated  with  those  functions. 

2.  Methodology 

The  products  of  the  preceding  Needs  Analysis  phase,  specifically  the  stakeholder  analysis 
and  mission  thread  definition  were  used  as  inputs  to  the  requirements  definition  task. 
Unclassified  Joint  and  Naval  doctrine  publications  were  researched  to  expand  upon  the  guidance 
provided  by  the  stakeholders  about  user  needs,  to  provide  context  to  the  mission  areas,  and  to 
provide  insight  into  how  the  SUW  and  MIO  mission  areas  would  be  performed.  The  derived  C2 
functions  specific  to  the  mission  areas  were  initially  compiled  in  a  Dynamic  Object-Oriented 
Requirements  System  (DOORS)  database  for  configuration  control  and  tracking  purposes. 
DOORS  is  a  commercially  available  requirements  management  software  tool.  This  data  was 
eventually  migrated  to  a  CORF  file  for  commonality  with  the  modeling  tool  intended  to  be  used 
to  validate  the  identified  functions. 

The  output  was  a  hierarchy  of  C2  functions  with  their  associated  requirements  and  metrics. 
These  functions  are  listed  in  the  table  in  Appendix  C.  "02  Requirements.  VSD  and  Architecture 
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Matrix'*  and  described  below.  Traceability  of  those  requirements  to  source  doctrine  publications 
was  also  recorded. 

3.  (General  Results 

A  total  of  77  functional  requirements.  29  performance  requirements  and  12  constraints  were 
derived  from  the  stakeholder  surveys  and  feedback,  from  the  mission  thread  activity  analysis, 
and  from  the  doctrine  publication  research.  Functional  requirements  describe  what  the  system 
must  be  able  to  do.  Pcrfomtancc  requirements  describe  how  well  the  system  must  perform. 
Constraint  requirements  describe  other  operational  or  design  limitations  with  which  the  system 
must  comply.  The  requirements  address  the  command  and  control  functions  of  surface  warfare 
in  general,  such  as  maintaining  surface  situational  awareness,  evaluating  contacts  and  developing 
engagement  orders,  plus  the  specific  additional  requirements  necessary  for  the  MIO  mission, 
such  as  C2  support  for  conducting  visits,  boarding,  searches  and  seizures,  and  for  reporting. 
Throughout  the  process,  it  was  discovered  that  detection,  tracking,  and  reporting  functionality 
was  common  for  the  MIO  and  SUW  threads.  Since  many  of  the  tactical  picture  requirements 
and  evaluation  needs  arc  common  to  both  combat  and  non-combat  situations,  the  majority  of  the 
requirements  make  no  distinction  between  MIO  and  SUW.  This  helped  avoid  generating  a  set  of 
redundant  requirements  due  to  the  artificiality  of  segmenting  along  mission  lines. 

The  requirements  arc  listed  in  Appendix  C,  along  with  the  performance  measures  developed 
during  the  VSD  stage.  Table  8  illustrates  a  short  excerpt  of  this  appendix.  Each  requirement  is 
tracked  by  number  in  a  hierarchical  arrangement  in  which  higher  level  requirements  arc 
decomposed  into  multiple  lower  level  requirements,  as  indicated  by  the  number  of  decimal 
points  in  the  requirement  number.  (Requirement  1.2  decomposed  into  1.2.1,  1.2.2,  etc.) 
Following  each  requirement  statement  is  the  source  information  for  that  requirement,  and  may  be 
attributed  to  a  Joint  or  Navy  publication,  a  stakeholder,  or  another  doctrinal  source. 
Requirements  that  do  not  reference  an  external  source  were  derived  as  necessary  to  ‘fill  in*  the 
architecture  when  required.  The  Type  column  indicates  whether  a  requirement  is  a  functional  or 
performance  requirement,  or  a  constraint.  The  Value  System  Design  column  further  describes 
the  requirement  in  terms  of  the  intended  objective  and  Measures  of  Performance  or  Effectiveness 
as  described  in  the  following  section. 
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Table  8:  C2  Requirements  and  VSD 

This  table  contains  a  partial  listing  for  illustratxm  purposes.  For  lull  listing  of  the  C2  requirements 
and  VSD  refer  to  Appendix  C. 


Requirement 

Rationale 

Type 

Value  System  Design 

1.2  Collect  Target  Information 

The  C2  system  shall  collect  target 
information  for  delecting, 
identifying,  locating,  and 
classifying  targets. 

NTA  2.2.1 

Functional 

Obj:  Determine  C2  capability  of  sensors  to 
identify  an  object  under  varied  noise,  weather, 
terrain  conditions 

Performance  Measure:  Ability  of  sensors  to 
identify  an  object  under  vaned  noise,  weather, 
terrain  conditions 

(ioal:  Probability  of  detection  and  classification 
>99% 

1.2.1  Receive  Sensor  Inputs 

The  C2  system  shall  utilise  rxlar. 
electro -oplK-al  infrared  (EQ1R ). 
electronic  surveillance  l  IIS), 
identification  fr>md  or*foc  (IFF | 
and  automatic  identification  system 
(AIS)  data  in  the  classification  and 
identification  of  contacts. 

(ioddin. 
20CK;  Haas 
&  Neel. 

20CS 

Functional 

Otoj:  Assess  C2  functionality  in  receiving  data 
from  sensors  in  detection.  ID.  and  classification  of 

contacts. 

PERFORMANCE  MEASURE:  Ability  of  C2  to 
cometly  and  accurately  detect.  Identify,  classify 
contacts  from  sense*  data 

(ioal:  Probability  of  correct  detection.  ID.  and 
classification  >85% 

One  of  the  lessons  learned  when  the  functions  were  evaluated  for  timing  requirements 
against  specific  threats  was  that  in  the  SUW  role,  the  timing  was  cither  non-stressing  or  overly 
so.  with  little  middle  ground.  Engagement  timelines  necessary  to  counter  representative  threats 
described  in  the  Threat  Analysis  (Section  II.  C.)  phase  of  this  report  were  calculated,  using  the 
threat's  expected  detection  range,  closure  rate  and  a  mandatory  safety  range.  These  timelines, 
expressed  in  minutes  or  seconds,  reflect  the  amount  of  time  the  ship  had  to  detect  and  collect 
target  information,  process  and  engage  the  target,  before  it  became  vulnerable  to  enemy  fire.  A 
timeline  allowance  of  zero  seconds  indicated  a  threat  that  was  capable  of  launching  a  weapon 
against  our  ship  at  or  beyond  our  ship's  detection  range  of  the  enemy.  Mandatory  safety  range 
was  the  maximum  range  at  which  the  threat  could  launch  a  weapon  against  our  ship.  Detection 
range  was  a  function  of  the  height  above  the  sea  surface  of  the  threat,  which  determined  the 
range  at  which  it  would  be  detectable  above  the  radar  horizon  in  nominal  RF  propagation 
conditions.  The  parameters  used  in  these  calculations  are  shown  in  Table  7,  "Summary  of  Threat 
Parameters."  For  example,  in  an  encounter  with  a  low  capability  surface  platform  that  must  close 
to  within  hundreds  of  yards  or  a  mile  of  the  ship,  such  as  a  FI  AC.  the  ship  had  several  minutes  to 
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detect,  assess,  decide  and  act  against  the  threat.  However,  against  a  peer-capability  such  as  a 
missile  amicd  destroyer  capable  ot*  launching  an  ASCM  from  beyond  the  hon/on.  the  capability 
of  engaging  in  a  surface  warfare  "shoot  the  archer*'  mode  was  essentially  non-existent.  The 
friendly  ship  must  engage  the  ASCM  in  an  air  defense  role,  unless  it  can  get  a  shot  against  the 
enemy  vessel  several  minutes  before  the  enemy  can  detect  own  ship  and  launch  a  missile.  Thus, 
the  SUW  engagement  timeline  was  typically  cither  zero  seconds  against  a  missile  ship  or  about 
1 5  minutes  against  a  FIAC/FAC. 

This  15  minute  timeline  represented  the  time  it  would  take  a  fast  surface  vessel  to  close  the 
distance  between  the  horizon  and  the  ship  assuming  the  ship  docs  not  contribute  to  or  mitigate 
the  threat's  rate  of  closure  by  high  speed  transit  toward  or  away  from  the  threat.  This 
engagement  timeline  would  be  allocated  across  several  of  the  performance  measures  listed  in 
Appendix  C.  "C2  Requirements."  principally  requirements  1.2  (Collect  Target  Information).  1.3 
(Process  Targets),  and  1.4  (Localize  Target),  and  their  sub-elements.  Although  notional  values 
were  assigned  to  several  of  these  pcrfomiancc  measures.  ditTerent  allocations  of  time  would  be 
acceptable  as  long  as  the  total  timeline  constraint  is  achieved.  These  measures  collectively 
constitute  the  trade  space. 

B.  VALUE  SYSTEM  DESIGN 

1.  Background 

The  Value  System  Design  (VSD)  is  a  hierarchy  of  objectives,  functional  requirements. 
Pcrfomiancc  Measures  (PMs).  and  their  goals.  Buede  defines  a  VSD  as  a  hierarchy  of  objectives 
that  are  important  to  the  system's  stakeholder*  (Buede.  2(KM)|.  The  VSD  is  a  process  and  a 
product  that  identifies  stakeholder  objectives  and  ties  them  to  requirements.  The  VSD  results  in  a 
product  that  traces  the  objectives  to  the  requirements  and  the  development  of  PMs  and  their 
associated  goals.  These  goals  and  metrics  add  value  and  meaning  to  what  each  functional 
requirement  entails.  In  short  the  VSD  is  the  bridge  between  the  Needs  Analysis  and  Functional 
Analysis  by  connecting  the  stakeholder's  objectives  to  the  requirements  definition  phase. 
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2.  Methodology 

The  VSD  effort  was  conducted  in  parallel  with  the  requirements  development.  The  VSD 
took  the  approach  of  identifying  the  objectives  defined  in  the  stakeholder  analysis  and  mapping 
those  objectives  to  respective  functional  requirements  defined  in  the  requirements  definition. 
Performance  and  Constraint  requirements  were  not  the  focus  of  the  VSD,  as  these  requirements 
identified  in  the  Requirements  Definition  phase  directly  represent  PMs  and  goals  self-contained 
within  these  requirements.  Although  the  VSD  was  not  focused  on  the  performance  and 
constraint  requirements,  the  VSD  maintained  the  general  hierarchy  that  was  developed  in  the 
requirements  definition.  It  is  through  the  use  of  this  hierarchy  that  the  VSD  was  able  to  maintain 
configuration  management  in  respect  to  the  work  done  on  the  requirements  definition.  In 
addition,  the  VSD  was  able  to  determine  several  requirements  that  could  be  grouped  within  a 
single  objective,  which  those  groups  of  requirements  could  be  addressed  by  one  or  two  PMs  and 
their  respective  goals. 

PMs  on  the  other  hand  were  derived  from  a  combination  of  mapping  the  objectives  to  the 
requirements  and  in  addition  from  supplemental  information  derived  from  the  Mission  Threads 
and  Threat  Assessment.  In  short  the  VSD's  PMs  were  pieces  of  information,  values,  and 
concepts  taken  from  each  of  the  respective  sections  discussed  above.  The  PMs  were  identified  to 
assess  each  requirement  to  determine  how  well  they  meet  mission  requirements,  stakeholder 
objectives,  and  associated  Navy  doctrine  and  publications.  It  is  through  the  interfacing  of  these 
sections  together  that  the  PMs  could  be  derived.  In  other  cases,  PMs  were  directly  taken  from 
Navy  Doctrine  and  Pubs. 

The  representative  PM  goals  and  values  were  based  upon  information  from  the 
stakeholder's  analysis.  Navy  doctrine  and  publications,  and  the  Navy  Task  List.  In  some  cases. 
PM  goals  were  not  included  in  order  to  maintain  the  project  at  an  unclassified  level.  In  these 
cases  the  goals  were  derived  for  these  particular  PMs.  The  results  of  the  VSD  were  organized 
into  a  tabular  format  to  demonstrate  how  requirements  fed  into  the  stakeholder  objectives  and 
lastly  how  PMs  were  derived  with  their  associated  goals.  The  VSD  alongside  with  the 
requirements  can  be  found  in  Appendix  C. 
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3.  Conclusion 


A  total  of  77  functional  requirements  were  identified  in  the  requirements  definition 
phase.  Of  those  77  requirements,  23  requirements  were  consolidated  to  support  the  same 
objectives.  PMs.  and  goals.  The  remaining  54  functional  requirements  were  addressed  with 
distinct  objectives,  PMs.  or  derived  values.  What  this  means  is  that  a  majority  of  the 
requirements  defined  in  the  requirements  definition  phase  had  distinctive  PMs  and  goals 
assigned  to  them  and  that  these  results  could  be  traced  back  to  the  stakeholder  objectives. 

The  VSD  essentially  provided  evidence  in  mapping  and  tracing  the  stakeholders' 
objectives  to  the  requirements  and  the  requirements  to  the  PMs  and  their  associated  values.  The 
VSD  validated  and  verified  that  the  requirements  definition  phase  captured  the  stakeholder 
objectives.  In  addition  the  VSD  provided  PMs  and  goals  that  can  be  utilized  for  further  study. 

C.  ENTERPRISE  ARCHITECTURE 

1.  Background 

The  enterprise  architecture  task  defines  the  required  behavior  of  the  C2  system,  the 
operational  activities  that  the  C2  system  must  support,  and  the  functionality  of  the  C2  system 
itself.  The  operational  activities  arc  based  on  current  SUW  and  MIC)  doctrine  identified  during 
the  Stakeholder  Analysis  task  of  the  Needs  Analysis  phase.  The  operational  activities  relied  the 
tasks  that  must  be  completed  in  support  of  the  missions  identified  in  the  Mission  Thread 
Analysis,  independent  of  their  implementation  in  specific  systems.  The  C2  system  functionality 
defines  what  the  C2  system  is  required  to  do  and  the  interfaces  with  external  systems  that  the  C2 
system  must  support.  The  enterprise  architecture  implements  key  inputs  from  the  stakeholder 
analysis,  namely  the  concepts  of  Distributed  Weapons  Coordination  (DWC)  and  Engage  on 
Remote  (EOR). 

DWC'  is  implemented  in  the  architecture  through  common  algorithms  for  threat 
ev  aluation  and  engagement  scheduling  and  the  sharing  of  effectiveness  data  between  platforms. 
In  essence,  each  platform  executes  a  common  algorithm  for  threat  evaluation.  Based  on  the 
resultant  common  threat  list,  each  platform  exchanges  engagement  effectiveness  estimates  with 
other  platforms.  The  engagement  effectiveness  inputs  feed  a  common  engagement  scheduling 
algorithm,  leading  to  common  engagement  assignments  across  the  force. 
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EOR  capability  permits  a  ship  to  engage  targets  being  tracked  by  other  platforms,  rather 
than  solely  those  for  which  it  has  its  own  sensor  data.  Since  each  platform  shares  the  same 
contact  report  inputs  and  the  same  tracking  algorithms,  this  contributes  to  a  common  track 
picture  between  platforms.  Once  the  common  track  picture  has  been  developed,  remote  tracks 
and  organic  (own  ship)  tracks  can  be  addressed  on  an  equal  basis,  with  no  outward  difference  to 
the  system  operator.  This  permits  the  most  capable  and  best  situated  sensor! s)  and  the  most 
capable  and  situated  w  eapons  system  to  be  utilized,  even  if  they  are  not  on  the  same  platform. 

Also,  during  the  architecture  task,  requirements  were  allocated  to  the  system's  functions. 
The  allocation  process  ensured  that  all  requirements  could  be  mapped  to  at  least  one  function, 
meaning  that  the  architecture  addressed  all  of  the  C2  system  requirements.  The  allocation 
process  also  ensured  that  all  functions  were  allocated  at  least  one  requirement,  meaning  that  all 
included  C2  system  functionality  supported  a  system  requirement.  In  cases  where  the  allocation 
of  requirements  to  the  system  functions  was  not  complete,  the  architecture  task  fed  the 
discrepancies  back  into  the  requirements  definition  to  clarify  the  C2  system  requirements.  A 
specific  example  of  the  feedback  to  the  requirements  task  includes  the  identification  of  three 
previously  undocumented  requirements:  to  allow  the  user  to  tailor  the  display,  to  receive  and 
process  the  OPT ASK  LINK  and  to  support  the  querying  of  commercial  ships  in  support  of  MIO. 

2.  Methodology 

The  DoDAF  was  used  to  describe  the  architecture  for  both  the  SUW  and  MIO  missions. 
The  framework  defines  three  related  views  of  the  architecture:  operational  view'  (OV),  systems 
viewf  (SV),  and  technical  standards  view  (TV).  Due  to  the  scope  of  this  project,  only  the  OV  and 
SV  were  used.  In  addition  to  the  OV-1  diagrams  presented  earlier  in  this  report,  three  other 
DoDAF  products  were  created:  the  operations  activity  model  (OV-5).  the  system  functionality 
description  (SV-4),  and  the  operational  activities  to  systems  function  traceability  matrix  (SV-5). 
The  OV-5  was  created  to  show  the  capabilities,  operational  activities,  relationships  among 
activities,  and  inputs  and  outputs  to  the  operational  activities.  The  SV-4  shows  the  system 
functionalities  and  data  flow  among  the  system  functions.  The  SV-5  shows  show  the  mapping  of 
system  functions  to  the  operational  activities. 

In  the  development  of  the  OV-5  and  SV-4  products,  the  CORF  Systems  Engineering  tool 
was  used  to  document  and  integrate  the  products.  CORF  allows  the  use  of  either  the  Integration 
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Definition  language  0  (IDEFO)  or  the  Enhanced  Functional  Flow  Block  Diagram  (EFFBD) 
methods  for  functional  modeling.  IDEFO  was  specifically  chosen  as  a  language  because  it 
supports  a  good  representation  of  concurrent  systems  that  do  not  demonstrate  sequential 
behavior.  IDEFO  shows  the  tasks  and  information  flows  within  a  system.  An  IDEFO  diagram 
shows  the  inputs,  controls,  outputs,  and  mechanisms  (1COMS)  for  an  activity  or  function.  An 
input  is  an  object  that  is  changed  as  a  result  of  the  activity  or  function.  A  control  is  an  object  that 
guides  or  regulates  the  activity  or  function.  An  output  is  an  object  that  is  the  result  of  the  activity 
or  function.  A  mechanism  is  a  system,  organization,  people,  etc.  that  support  or  perform  the 
activity  or  function  |  National  Institute  of  Standards  and  Technology.  2009].  The  OV-5  and  SV-4 
diagrams  below  do  not  include  any  mechanisms.  The  architecture  is  intended  to  define  the 
required  functional  behavior  of  the  C2  system  and  not  the  design  of  the  physical  system  itself. 

Dunng  the  development  of  the  OV-5.  the  NTTL  was  referenced  for  operational  activities 
[Office  of  the  Chief  of  Naval  Operations.  2007 1.  There  were  some  specific  cases  where  the 
activities  defined  were  not  directly  taken  from  the  NTTL.  These  cases  were  whenever  there  was 
an  activity  specific  to  the  architecture  that  needed  to  be  defined  that  was  not  clearly  included 
within  the  NTTL. 

The  OV-5  development  was  also  based  upon  the  SUW  and  MIO  mission  threads  defined 
in  Section  II.B  “Mission  Threads  Analysis/*  Key  concepts  of  classification,  identification, 
application  of  ROEs.  input  of  weapon  status,  commercial  ship  queries,  issuance  of  the 
engagement  order  and  engagement  assessment  were  translated  directly  into  the  OV-5.  However, 
the  OV-5  goes  into  greater  detail  than  the  mission  threads  in  certain  areas,  specifically  in  the 
exchange  of  data  via  the  track  file,  further  decomposition  of  guidance  such  as  ROE  into 
preplanned  responses,  classification  and  identification  criteria,  weapons  release  criteria  and 
expansion  of  external  inputs  such  as  intelligence  data  and  Operation  Tasks  (OPT ASK). 

Dunng  the  development  of  the  SV-4,  the  Surface  Navy  Combat  Systems  Product  Line 
Software  Architecture:  Architecture  Description  Document  [Program  Executive  Office  for 
Integrated  Warfare  Systems.  2008 1  was  used  as  the  source  for  the  top-level  functions,  where  the 
top-level  functions  map  to  the  domains  within  the  document.  As  with  the  OV-5,  top-level 
functions  were  added  as  ncccssaiy  when  specific  functionality  needed  to  be  called  out  that  was 
not  present  within  the  Architecture  Description  Document  at  the  domain  level. 
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3.  Architecture  Products 


The  following  diagrams  represent  the  architecture  for  the  C2  system.  Figure  19  through 
Figure  22  and  accompanying  descriptions  pertain  to  the  OV-5  for  the  C2  system.  Figure  23  is 
the  external  system  diagram.  Figure  24  through  Figure  27  diagrams  and  descriptions  pertain  to 
the  SV-4.  Finally,  the  SV-5  is  shown  in  Table  9. 

a.  Operational  Activities 

Perfomi  C2  consists  of  three  operational  activities:  Collect  Target  Information  (NT A 
2.2.1).  Process  Targets  (NTA  3.1)  and  Maintain  Information  and  Naval  Force  Status  (NTA 
5.1.3).  The  OV-5  AO  diagram  for  Perform  C2  is  shown  in  Figure  19. 


Figure  19:  OV-5  AO  Diagram  for  Perform  C2 

The  OV*5  AO  Diagram  contains  three  operational  activities:  Collect  Target  Information*  Process 
Targets,  and  Maintain  Inforrmtion  and  Naval  Force  Status. 


The  first  operational  activity  is  '’Collect  Target  Information,"  which  encompasses  the 
tracking,  classification,  and  identification  of  surface  contacts.  This  activity  uses,  contact  reports 
from  external  sensors,  external  track  files,  ship  self-identification  data  from  AIS.  intelligence 
data  as  inputs,  query  responses  from  surface  contacts.  As  controls,  this  activity  uses  the  set  of 
internally  maintained  track  files  and  the  classification  and  identification  criteria.  This  activity 
outputs  a  query  to  a  surface  contact,  new  track  file,  or  a  track  file  update. 

The  second  operational  activity  is  ’’Process  Targets."  which  includes  the  selection  of 
targets,  the  allocation  of  targets  to  weapons,  and  the  issuance  of  the  order  to  engage.  This 
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activity  uses  weapons  status  and  external  engagement  effectiveness  estimates  as  inputs  and 
outputs  an  order  to  fire,  external  engagement  effectiveness  estimates,  boarding  order,  and  track 
file  updates  indicating  engagement  status  on  the  track.  The  controls  for  this  activity  are  the 
weapons  release  criteria,  the  set  of  internally  maintained  track  files,  and  the  pre-planned 
responses. 

The  third  operational  activity  is  "Maintain  Information  and  Naval  Force  Status.”  which 
provides  for  the  maintenance  and  display  of  the  tactical  picture,  unit  status,  and  force  command 
and  coordination  status.  This  activity  uses  track  file  updates,  new  track  files,  intelligence  data  to 
maintain  the  tactical  picture,  and  weapons,  boarding,  and  sensor  statuses  to  maintain  unit  status 
as  inputs.  The  controls  for  this  activity  are  the  operation  tasks  (OPTASK s)  LINK.  MIO  SUPP. 
and  SUW.  OPTASK  LINK  is  the  information  required  to  establish  the  link  network.  OPTASK 
MIO  SUPP  describes  the  authority  required  to  conduct  each  MIO  task,  rules  of  engagement,  the 
format  and  frequency  of  situation  reports  (SITRHPs),  and  any  other  specific  required  procedures 
during  boarding.  OPTASK  SUW  describes  authorities,  rules  of  engagement,  reporting 
requirements,  and  other  information  required  to  conduct  SIJW  operations.  This  activity  outputs 
track  tiles,  the  boarding  communication  plan  (COM PLAN),  and  SITRHPs  to  external  commands. 
It  uses  the  OPTASKs  to  produce  a  number  of  additional  outputs  that  arc  controls  for  other 
activities,  including  the  set  of  internal  track  files,  weapons  release  criteria,  pre-planned 
responses,  and  classification' identification  criteria. 

The  "Collect  Target  Information”  operational  activity  is  decomposed  into  three  sub- 
activitics  as  shown  in  Figure  20.  These  sub-activities  include  the  following:  Track  Contacts. 
Classify  Contacts,  and  Identify  Contacts. 
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Figure  20:  OV-5  A1  Diagram  for  C  ollect  Target  Information 

This  figure  is  the  decomposition  of  the  “Collect  Target  Information’*  activity. 

The  first  sub-activity  is  “Track  Contacts/"  w  hich  accepts,  inputs  of  contact  reports  from 
both  own-ship  and  external  systems  as  well  as  external  track  files.  An  internally  maintained 
track  file  provides  the  control  for  this  activity.  The  Track  Contents  activity  utilizes  these  inputs 
to  create  an  update  to  the  internal  track  file,  along  with  an  output  of  a  new  external  track  file.  The 
use  of  both  own-ship  and  external  contact  reports  in  the  generation  of  new  track  files  and  track 
file  updates  implements  the  FOR  capability. 

The  second  sub-activity  is  “Classify  Contacts/"  which  requires  the  internal  track  file  and 
classification  and  identification  criteria  as  controls.  These  controls  allow  the  activity  to  output  a 
track  file  update  with  the  classification  parameter  added. 

The  third  sub-activity  is  “Identify  Contacts/*  which  requires  ship  self-identification  data 
from  A1S.  intelligence  data,  and  query  responses  as  inputs  in  conjunction  with  the  internal  track 
file  and  classification-identification  criteria  controls.  This  activity  uses  these  outputs  as  a  query' 
to  a  surface  contact  and  outputs  a  track  file  update  with  the  identification  parameters  added. 

The  "Process  Targets*"  operational  activity  is  decomposed  into  six  sub-activities  as  shown 
in  Figure  21.  These  sub-activities  include  the  following:  Request  Attack,  Select  Target  to 
Attack.  Select  Platform(s)  and  Systcm(s)  for  Attack.  Develop  Order  to  Fire,  Conduct  Tactical 
C  ombat  Assessment,  and  Select  Ship  to  Visit.  Board,  and  Search. 
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Figure  21:  OV-5  A2  Diagram  for  Process  Targets 

This  figure  ix  the  decomposition  of  the  “Proecs*  Targets*'  activity. 


The  first  sub-activity  is  “Request  Attack,*'  which  utilizes  the  controls  of  weapons  release 
criteria,  pre-planned  responses,  and  track  files  to  develop  a  target  nomination.  This  target 
nomination  is  output  directly  into  the  second  sub-activity.  “Select  Target  to  Attack.'*  The  “Select 
Target  to  Attack'*  sub-activity  utilizes  this  input  and  the  same  controls  as  the  first  sub-activity  to 
select  a  target,  which  is  an  output  to  the  third  sub-activity.  “Select  Platform(s)  and  Systcm(s)  for 
Attack."  These  two  activities  employ  a  threat  evaluation  algorithm  that  is  common  across  the 
force  in  support  of  Distributed  Weapons  Coordination. 

The  “Select  Platform(s)  and  Systcm(s)  for  Attack'*  sub-activity  utilizes  target  selection, 
weapons  status,  and  external  engagement  effectiveness  estimates  as  inputs.  As  controls,  this 
activity  uses  the  weapons  release  criteria  and  pre-planned  responses.  This  activity  outputs  own- 
ship  engagement  effectiveness  estimates  and  uses  both  own-ship  and  external  engagement 
effectiveness  estimates  when  executing  an  engagement  scheduling  algorithm  that  is  common 
across  the  force  to  support  DWC.  This  activity  creates  a  weapon  assignment. 
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The  fourth  sub-activity  is  “Develop  Order  to  Fire/'  which  requires  the  weapon 
assignment  as  an  input  and  the  pre-planned  responses  as  a  control.  This  activity  uses  these 
inputs  to  generate  an  order  to  fire  and  a  track  file  update. 

The  fifth  sub-activity  is  “Conduct  Tactical  C  ombat  Assessment/*  which  requires  no 
input,  but  uses  the  track  file  as  a  control.  Additional  information  is  added  to  the  track  file,  which 
leads  to  a  track  file  update  output. 

The  sixth  sub-activity  is  “Select  Ship  to  Visit.  Board,  and  Search/'  which  requires  no 
input  and  uses  the  track  file  as  a  control.  This  activity  may  output  a  boarding  order,  if  a  ship  is 
selected  to  visit,  board,  and  search.  Obviously,  this  activity  is  distinct  to  a  MIO  activity  and 
would  not  be  activated  in  an  engagement  scenario.  This  sub-activity  within  the  Process  Targets 
activity  reinforces  the  concept  that  the  OV-5  is  a  common  functional  set  that  can  be  applied 
across  both  the  SUW  and  MIC)  mission  threads  and  all  activities  may  not  be  applicable  in  all 
scenarios. 

The  “Maintain  Information  and  Naval  Force  Status'*  operational  activity  is  decomposed 
into  three  sub-activities  as  shown  in  Figure  22.  These  sub-activities  include  the  following: 
Maintain  and  Display  Tactical  Picture.  Maintain  and  Display  Force  Command  and  Coordination 
Status,  and  Maintain  and  Display  Unit  Readiness. 


Figure  22:  OV-5  A3  Diagram  for  Maintain  Information  and  Naval  Force 
Status 


Thu  figure  is  the  decomposition  of  the  “Maintain  Information  and  Naval  Fonre*  Slalu*~  activity. 
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The  first  sub-activity  is  “Maintain  and  Display  Tactical  Picture,”  which  requires 
intelligence  data,  a  new  track  file,  and  a  track  file  update  as  inputs.  This  activity  uses  these 
inputs  along  with  link  settings  from  the  second  sub-activity.  “Maintain  Display  Force  Command 
and  C  oordination  Status.'*  as  a  control  to  create  track  files  and  tactical  picture  metrics. 

The  “Maintain  and  Display  Force  Command  and  Coordination  Status'*  sub-activity 
requires  OPTASKs  LINK.  MIO  SUPP.  and  SUW  as  controls  to  generate  and  output  the  link 
settings  required  in  the  “Maintain  and  Display  Tactical  Picture"  sub-activity  and  to  output 
classification  and  identification  criteria,  a  boarding  COMPLAN.  weapons  release  criteria,  and 
pre-planned  responses. 

The  third  sub-activity  is  “Maintain  and  Display  Unit  Readiness.*'  which  utilizes  the 
tactical  picture  metrics  from  the  “Maintain  and  Display  Tactical  Picture**  sub-activity,  along  with 
sensor,  weapon,  and  boarding  statuses  as  inputs.  This  activity  uses  the  OPTASK  LINK. 
OPTASK  MIO  SUPP.  and  OPTASK  SUW  as  controls.  This  activity  uses  these  inputs  and 
controls  to  generate  SITREPs. 

b.  Functional  Descriptions 

The  C2  system  must  interface  with  other  own-ship  and  external  systems  or  entities.  An 
external  system  diagram  shows  the  external  systems  and  entities  that  the  C2  system  interfaces 
with  and  the  data  flows  between  them.  The  external  systems  arc:  intelligence  agency,  own-ship 
sensor  systems.  SUW  Commander  (SUWC)  or  MIO  combat  operations  center  (COC).  other 
platform  sensor  and  C2  systems,  commercial  ships,  own-ship  weapons  systems,  and  boarding 
party.  The  A-l  external  system  diagram  for  Perform  C2  is  shown  in  Figure  23. 
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Figure  23:  A- 1  External  System  Diagram  for  Perform  C2 

Thu  is  the  context  diagram  for  the  Perform  C2  Function  and  depicts  the  external  systems  with 
which  the  C2  system  interacts. 

Perform  C2  consists  of  four  functions:  Display  Tactical  Data.  Perform  Track 
Management.  Conduct  Combat  Control,  and  Report  Status.  The  SV-4  AO  diagram  for  Perform 
C2  is  shown  in  Figure  24. 
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Figure  24:  SV-4  AO  Diagram  for  Perform  C2 

The  SV-4  AO  Diagram  contain*  four  operational  activity*:  Display  Tactical  Data.  Perfonti  Track 
Management.  C  onduct  Combat  Control,  and  Report  Status. 

The  first  function  is  “Display  Tactical  Data,**  which  includes  displaying  tactical  data  and 
various  statuses.  This  function  uses  boarding,  sensor,  and  weapon  statuses  and  tactical  picture 
metrics  as  inputs.  As  controls,  this  function  uses  the  following:  the  set  of  internally  maintained 
track  files  from  the  second  function  “Perform  Track  Management/*  OPTASKs  LINK.  MIO 
SUPP,  and  SUW,  airspace  coordination  ordcn>.  and  friendly  and  neutral  ship  locations.  This 
function  docs  not  have  any  outputs.  The  “Display  Tactical  Data**  function  produces  the  display 
as  output  to  the  system  operator.  The  decision  was  made  to  leave  the  display  output  off  the 
diagram  as  it  was  inconsistent  w  ith  outputs  such  as  Track  Files  that  represent  data  exchanged 
between  functions. 

The  “Perform  Track  Management**  sub-function  consists  of  the  formation,  classification, 
identification,  correlation  and  decorrelation,  and  bearing  and  fix  association  of  tracks.  This 
function  uses  several  inputs:  ship  self-identification  data  from  A1S.  contact  reports  from  external 
sensors,  electronic  warfare  (E\V)  bearings,  external  track  tiles,  intelligence  data,  quay  responses, 
and  track  file  updates  from  the  third  function  “Conduct  Combat  Control.**  The  controls  for  this 
function  arc  the  link  settings  and  classification  and  identification  criteria  from  the  “Conduct 
C  ombat  Control  function.'*  This  function  outputs  track  tiles,  which  the  “Display  Tactical  Data*' 
function  also  uses  as  a  control,  and  tactical  picture  metrics,  which  is  an  input  to  the  “Display 
Tactical  Data"  function. 
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The  third  function  is  “Conduct  Combat  Control/'  which  includes  assessing  and 
prioritizing  threats,  issuing  engagement  or  boarding  orders,  and  assessing  the  engagement.  This 
function  utilizes  weapon  status,  environmental  data,  and  external  engagement  effectiveness 
estimates  as  inputs.  The  controls  for  this  function  arc  the  same  as  the  ones  used  by  the  “Display 
Tactical  Data"  function.  Track  files  are  represented  as  a  control  and  not  as  an  input  because  they 
guide  how  the  function  prioritizes  threats,  issues  orders  and  assesses  engagement.  However,  the 
track  tiles  are  not  directly  modified  by  the  function  during  execution.  Track  tile  updates  are 
produced  and  incorporated  into  the  track  tiles  within  the  Track  Management  function.  The 
‘Conduct  Combat  Control"  function  has  several  outputs:  link  settings  and  classification  and 
identification  data,  which  arc  used  as  controls  by  the  "Perform  Track  Management"  function, 
sensor  plans,  order  to  fire,  queries,  boarding  order*.  boarding  COM  PLAN,  and  track  tile  updates, 
which  arc  used  as  an  input  by  the  “Perform  Track  Management"  function.  The  "Conduct 
Combat  Control"  function  also  exports  engagement  effectiveness  estimates  in  support  of  the 
Distributed  Weapons  Control  concept. 

The  fourth  function  is  "Report  Status."  which  includes  the  sending  of  SITREPs  to  higher- 
level  commands.  This  function  used  boarding,  sensor,  and  weapon  statuses  as  inputs.  The 
controls  for  this  function  are  OPTASKs  MIC)  SIJPP  and  OPTASK  SUW.  This  function  utilizes 
these  inputs  and  controls  to  generate  SITRF  Ps. 

The  "Display  Tactical  Data"  function  is  decomposed  into  live  sub- functions  as  shown  in 
Figure  25.  These  sub- functions  include  the  following:  Provide  Tactical  Display  Configuration 
Options.  Display  Track  Data.  Display  Engagement  or  VBSS  Status.  Display  Sensor  Status,  and 
Display  Command  Data. 


Figure  25:  SV-4  A I  Diagram  for  Display  Tactical  Data 


Thu  tiu.urc  is  the  decomposition  of  the  Display  Tactical  Data  functiixv 


The  first  sub-function  is  ‘'Provide  Tactical  Display  Configuration  Options/*  which  docs 
not  have  any  inputs,  but  uses  the  display  output  from  the  four  display  functions  as  a  control.  The 
display  output  serves  as  a  control  to  the  “Provide  Tactical  Display  Configuration  Options** 
function  because  the  function  does  not  directly  modify  the  display.  Rather,  the  function  provides 
display  setting  to  the  various  display  functions.  This  function  outputs  display  configuration 
settings,  which  arc  used  as  a  control  for  the  four  display  functions. 

The  second  sub-function  is  “Display  Track  Data.*'  which  uses  tactical  picture  metrics  as 
an  input.  The  controls  for  this  function  arc  the  display  configuration  settings  from  the  “Provide 
Tactical  Display  Configuration  Options*'  function,  airspace  coordination  order,  friendly  and 
neutral  ship  locations,  and  track  files.  This  function  provides  the  display  component  for  track 
data. 

The  third  sub-function  is  “Display  Engagement  VBSS  Status.*"  which  uses  weapon  and 
boarding  statuses  as  inputs.  The  controls  for  this  function  arc  the  display  configuration  settings 
from  the  “Provide  Tactical  Display  Configuration  Options'*  function  and  track  files.  This 
function  provides  the  display  component  for  VBSS  and  engagement  status  data. 


The  fourth  sub-function  is  “Display  Sensor  Status,"  which  includes  sensor  status  as  an 
input.  The  control  for  this  function  is  the  display  configuration  settings  from  the  “Provide 
Tactical  Display  Configuration  Options’*  function.  This  function  provides  the  display  component 
for  sensor  status. 

The  fifth  sub-function  is  “Display  Command  Data.'*  which  docs  not  have  any  inputs,  but 
uses  OPTASK  LINK.  OPTASK  MIO  SUPP.  and  OPTASK  SUW  and  the  display  configuration 
settings  from  the  “Provide  Tactical  Display  Configuration  Options'*  function  as  controls.  This 
function  provides  the  display  component  for  command  data,  such  as  the  OPTASKs. 

The  “Perform  Track  Management*'  function  is  decomposed  into  seven  sub- functions  as 
shown  in  Figure  26.  These  sub-functions  include  the  following:  Store  and  Report  Tracks.  Form 
Tracks.  Classify  Tracks.  Identify  Tracks.  Correlate  and  Dccorrclatc  Tracks.  Associate  Bearings 
and  Fixes  to  Tracks,  and  Manage  Track  Numbers. 


This  figure  ix  the  decomposition  of  the  Perform  Track  Management  function. 

The  first  sub-function  is  ‘'Store  and  Report  Tracks.'*  which  uses  external  track  files,  track 
tile  updates  from  the  six  other  sub- functions,  and  new  track  tiles  from  the  second  sub-function. 
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"Form  Tracks  "  as  inputs.  The  control  tor  this  function  is  the  link  settings.  This  function  outputs 
tactical  picture  metrics  and  track  files  that  arc  used  as  controls  by  the  six  other  sub-functions. 

The  "Form  Tracks"  sub-function  uses  contact  reports  from  own-ship  and  external  sources 
as  an  input.  The  controls  for  this  sub-function  arc  link  settings  and  track  files  from  the  "Store 
and  Report  Tracks"  sub-function.  New  track  files  and  track  file  updates  arc  outputs  that  arc  then 
used  as  inputs  to  the  "Store  and  Report  Tracks"  sub-function.  The  use  of  both  own-ship  and 
external  contact  reports  to  form  new  track  files  ami  track  file  updates  represents  the  EOR 
capability. 

The  third  and  fourth  sub-functions  arc  "Classify  Tracks"  and  "Identify  Tracks/' 
respectively.  The  "Classify  Tracks"  sub-function  docs  not  have  an  input  while  the  "Identify 
Tracks"  sub- function  uses  intelligence  data,  query  responses,  and  ship  self-identification  data 
from  AIS  as  inputs.  Both  use  track  files  and  classification  and  identification  criteria  as  controls 
and  output  track  file  updates. 

The  fifth,  sixth,  and  seventh  sub-functions  arc  "Corrclatc.'Dccorrclatc  Tracks."  "Associate 
Bearings' Fixes  to  Tracks."  and  "Manage  Track  Numbers,"  respectiv  ely.  The 
"Corrclatc/Dccorrclatc  Tracks"  and  "Manage  Track  Numbers"  sub- functions  do  not  have  any 
inputs  while  the  "Associate  Bearings’ Fixes  to  Tracks"  sub-function  uses  EW  bearings  as  an 
input.  Each  sub-function  use  link  settings  and  track  files  as  controls  and  outputs  track  file 
updates. 

The  "Conduct  Combat  Control"  function  is  decomposed  into  seven  sub-functions  as 
shown  in  Figure  27.  These  sub- functions  include  the  following:  Assess  and  Prioritize  Threats. 
Determine  Weapon  Target  pairing  Options.  Issue  Engagement  Order.  Query  Ship.  Issue 
Boarding  Order.  Develop  Execution  Guidance,  and  Assess  Engagement. 
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This  figure  ix  the  decomposition  of  the  Conduct  Combat  Control  function. 

The  first  sub-function  is  “Assess  and  Prioritize  Threats,*'  which  docs  not  have  an  input, 
but  uses  OPTASKs  MIO  StJPP  and  SUW.  track  files,  and  outputs  from  the  “Develop  Execution 
Guidance**  sub-function,  pre-planned  responses,  and  weapons  release  criteria  as  controls.  To 
support  the  DWC  concept,  the  “Assess  and  Prioritize  Threats**  sub-function  uses  a  threat 
evaluation  algorithm  that  is  common  across  the  force.  This  sub-function  outputs  threat  responses 
directly  into  the  second  sub-function  “Determine  Weapon  Target  Pairing  Options.** 

The  “Determine  Weapon  Target  Pairing  Options**  sub-function  uses  the  threat  responses 
from  the  “Assess  and  Prioritize  Threats**  sub-function  and  weapon  status  as  inputs.  The  controls, 
for  this  sub-function  arc  airspace  coordination  order,  friendly  and  neutral  ship  locations,  pre¬ 
planned  responses  from  the  sixth  sub-function  “Develop  Execution  Guidance.**  and  OPTASKs 
MIO  SUPP  and  SUW.  The  “Determine  Weapon  Target  Pairing  Options**  sub-function  supports 
the  DWC  concept  by  exporting  own-ship  engagement  effectiveness  estimates  and  by  using  both 
own-ship  and  external  engagement  effectiveness  estimates  as  inputs  to  develop  the  weapon- 
target  pairing  options.  This  sub-function  outputs  weapon  target  pairing  options  directly  into  the 
third  sub-function  “Issue  Engagement  Order.** 

The  “Issue  Engagement  Order**  sub-function's  only  input  is  the  aforementioned  weapon 
target  pairing  options.  The  controls  for  this  sub-function  arc  OPTASKs  MIO  SUPP  and  SUW 
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and  pre-planned  responses  from  the  ‘'Develop  Execution  Guidance*"  sub-function.  In  support  of 
DWC,  the  “Issue  Engagement  Order  *  sub-function  employs  a  weapon  scheduling  algorithm  that 
is  common  across  the  force.  This  sub-function  outputs  a  track  file  update  and  an  order  to  fire. 

The  fourth  sub-function  is  “Query  Ship.”  which  docs  not  have  an  input,  but  uses 
OPTASK  MIO  SUPP,  track  tiles,  and  pre-planned  responses  from  the  “Develop  Execution 
Guidance”  sub-function  as  controls.  This  sub-function  outputs  a  track  file  update  and  a  quciy. 

The  fifth  sub-function  is  “Issue  Boarding  Order.”  which  docs  not  have  an  input,  but  uses 
OPTASK  MIO  SUPP  and  track  files  as  controls.  This  sub-function  outputs  a  track  file  update,  a 
quciy  .  and  a  boarding  order. 

The  sixth  sub-function  is  “Develop  Execution  Guidance,”  which  uses  environmental  data 
as  an  input.  The  controls  for  this  sub-function  arc  OPTASK s  LINK.  MIO  SUPP.  and  SUW. 
Outputs  for  this  sub-function  include:  sensor  plans,  link  settings,  classification  and  identification 
criteria,  boarding  COM  PLAN,  pre-planned  responses,  and  weapons  release  criteria. 

The  seventh  sub-function  is  “Assess  Engagement.”  which  docs  not  have  an  input  and 
uses  track  tiles  as  a  control.  This  sub-function  outputs  a  track  tile  update. 

After  creating  the  OV-5  and  SV-4  diagrams,  the  SV-5  was  created  to  show  the 
traceability  between  the  operational  activities  and  system  functions  as  shown  in  Table  9.  In  an 
SV-5.  only  the  leaf-level  functions  arc  mapped  to  their  corresponding  leaf-level  operational 
activities.  The  top-level  functions  and  operational  activities  arc  included  in  the  diagram  to  help 
the  reader  trace  the  system  function  to  operational  activity  mapping  to  the  architecture  diagrams. 
An  *X'  placed  in  the  matrix  indicates  that  the  system  function  implements  that  operational 
activity.  All  system  functions  map  to  at  least  one  operational  activity  and  vice  versa.  This 
ensures  that  all  activities  arc  supported  by  the  system  functions  and  that  no  system  functions 
exists  that  do  not  support  some  operational  activity.  The  verification  of  the  enterprise 
architecture  is  discussed  in  Section  IV. A  “Modeling  and  Simulation”. 
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I  ablc  9:  SV-S 

The  table  imbcatcv  which  system  functions  are  used  to  satisfy  the  opera! iixial  activities. 
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4.  Conclusions 


The  required  behavior  of  the  C2  system,  which  was  based  on  the  system's  requirements, 
was  defined  by  the  enterprise  architecture.  This  enterprise  architecture  tor  the  C2  system  can 
effectively  support  both  the  SU\V  and  MIO  missions  without  the  need  for  separate  C2  system 
architectures.  The  operational  activities  that  the  systems  support  arc  defined  by  the  OV-5 
diagrams.  Then,  the  external  system  diagrams  are  used  to  show  the  external  systems  and  entities 
that  the  system  interfaces  with  to  support  the  mission.  Next,  the  C2  system's  functions  are 


defined  by  the  SV-4  diagrams.  Finally,  the  system's  functions  are  mapped  to  the  operational 
activities  via  the  SV-5.  During  the  M&S  task,  which  is  described  later  in  this  report.  COREsim 
and  CPN  validate  the  architecture  to  ensure  that  it  is  consistent  and  executable. 
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IV.  MODELING  AND  ANALYSIS 


The  Modeling  and  Analysis  phase  provides  modeling  and  simulation  results  to  verify  the 
architecture,  and  cost  analysis  to  identify  and  quantify  potential  cost  savings  as  a  result  of 
adopting  a  common  C2  architecture  for  Navy  surface  combatants.  Similar  to  the  previous  phase, 
the  requirements,  architecture,  mission  threads,  and  threats  were  re-evaluated  as  appropriate  and 
the  stakeholder*  were  contacted  in  order  to  ensure  the  project  remained  on  task  with  the 
stakeholders'  needs  (as  verifying  the  architecture  served  as  an  integral  part  of  the  requirements 
and  architecture  development  process).  The  Modeling  and  Analysis  phase  resulted  in 
architecture  verification  and  summarized  analysis  of  the  life-cycle  cost  savings  from  the 
consolidation  of  training  modules. 

A.  MODELING  AND  SIMULATION 

Two  different,  but  complementary.  M&S  techniques  were  used  to  model  the  C2  system 
architecture:  discrete-event  simulation  using  COREsim,  and  state  space  analysis  using  Colored 
Petri  Nets  (CPN).  The  objectives  for  the  verification  effort  were  to  determine  architecture 
completeness,  to  assess  internal  consistency  within  the  architecture,  and  to  verify  that  the 
architecture  was  executable.  If  not  complete,  consistent,  and  executable,  then  the  M&S  activities 
identify  the  specific  deficiencies  and  adjustments  needed  to  correct  the  architecture.  COREsim 
supports  architecture  verification  by  demonstrating  successful  execution  of  an  Enhanced 
Functional  Flow  Block  Diagram  (EFFBD)  representation  of  the  architecture  through  a  finite 
number  of  simulation  runs.  CPN  uses  a  state  space  analysis  to  identify  logical  issues  that  might 
not  be  uncovered  in  a  fixed  number  of  simulation  runs. 

1.  Architecture  Verification  using  COREsim 
a.  COREsim  Background 

CORE  is  a  model-based  systems  engineering  (MBSE)  tool  with  an  integrated  discrete  event 
simulator  called  COREsim.  which  is  used  to  create  and  execute  a  dynamic  view'  of  the 
architecture  in  order  to  verify  logic,  sequencing,  and  information  flows.  COREsim  uses  the 
Enhanced  Functional  Flow  Block  Diagram  (EFFBD)  view  of  the  architecture  associated  with 
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both  the  OV-5  and  SV-4.  The  EFFBD.  as  a  dynamic  process-oriented  view  of  the  architecture, 
provides  information  about  operational  activities  or  system  functions  that  are  not  captured  by  the 
other  views,  such  as  sequencing  of  events.  The  EFFBD  also  uses  logic  control  constructs  to 
specify  the  behavior  of  the  system  in  response  to  stimuli  (called  triggers  in  CORF).  Use  of  the 
simulator  to  step  through  the  dynamic  process  model  can  reveal  errors  in  the  How  of  information 
between  activities  or  functions  that  are  not  apparent  by  looking  at  the  IDEFO  diagrams. 

The  default  FFFBD  views,  produced  automatically  within  CORF  for  both  the  operational 
activities  and  the  system  functions,  show  all  activities  and  functions  in  numeric  sequential  order 
along  a  single  branch.  To  provide  a  more  realistic  view  of  the  dynamic  system,  the  model  can  be 
modified  to  include  a  variety  of  logic  structures,  such  as  parallel  branches,  "and' or”  and 
"lf'thcn'clsc  ‘  constructs,  iterates,  loops,  and  exits.  CORE  documentation  |Vitcch  Corp.  20(>0| 
indicates  that  there  arc  two  ways  to  represent  the  concept  of  concurrency.  The  first  is  through 
the  "iterate”  construct,  which  allows  for  the  processing  of  multiple  tracks  in  sequence  (not  truly 
concurrent).  The  second  is  through  the  "replicate”  construct,  which  allows  for  the  processing  of 
multiple  tracks  simultaneously  from  a  single  control  function.  However,  since  the  "replicate” 
construct  is  not  currently  enabled  in  CORF,  there  is  no  explicit  way  to  represent  the  parallel 
processing  of  multiple  tracks  or  targets.  Parallel  branches  can  be  used  to  represent  the 
concurrent  processing  of  activities  or  functions,  but  applies  to  only  one  target  or  track  at  a  time. 

b.  Verification  Techniques 

CORFsim  was  used  to  develop  and  execute  the  FFFBD  views  of  both  the  operational 
activities  and  the  system  functions.  Modifications  were  made  to  accommodate  the  differences 
between  the  IDEFO  specification  and  the  CORFsim  EFFBD  modeling  conventions  in  order  to 
create  an  executable  model.  The  default  FFFBDs  were  not  executable  due  to  violations  of 
CORFsim  rules.  CORFsim  reads  IDFFO  controls  as  triggers  in  the  FFFBDs,  which  is  not 
desirable  for  items  such  as  doctrinal  or  other  guidance  documents.  A  trigger  in  the  FFFBD  is 
used  to  initiate  the  execution  of  an  activity  or  function.  A  control  in  IDFFO  is  used  to  represent 
information  that  guides  or  regulates  how  an  activity  is  supposed  to  execute. 

CORFsim  also  requires  all  trigger*  to  come  from  activities  or  functions  that  arc  explicitly 
represented  in  the  model.  As  an  example,  information  from  external  sensor  systems  arc 
represented  as  controls  on  the  C2  system  in  the  IDFFO  diagrams,  but  are  treated  as  triggers  in  the 
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EFFBD.  These  triggers  were  converted  to  inputs  in  order  to  allow  the  simulation  to  execute. 
Then  the  activity  "New  Track  File  Arrives”  was  added  to  the  C2  operational  activity  EFFBD 
(Figure  28)  to  provide  the  initial  triggering  function  as  a  proxy  for  the  external  sensor  systems. 
The  activity  "Wait”  was  also  added  to  the  C2  operational  activity  EFFBD  (Figure  28Figure  28: ) 
to  control  the  time  lapse  between  track  arrivals.  Similar  changes  were  made  to  the  C2  system 
function  EFFBD  (Figure  3 1 ). 

The  conversion  of  external  system  1DEF0  controls  to  EFFBD  inputs  and  the  addition  of 
activities  and  functions  to  make  the  EFFBD  executable  substantively  changed  the  IDEFO 
representation  of  the  architecture.  Thus,  it  was  necessary  to  maintain  two  versions  of  the  CORE 
model:  the  original  with  properly  described  IDEFO  diagrams  and  a  simulation  version  with 
COREsim  executable  EFFBDs. 

In  addition  to  the  adjustments  required  to  allow  the  EFFBDs  to  execute  in  COREsim, 
adjustments  were  made  to  the  sequencing  of  activities  and  functions  to  more  closely  reflect 
reality.  Parallel  processing  was  used  to  reflect  concurrency  of  the  operational  activities  and 
system  functions,  where  applicable.  Triggers  were  used  to  control  sequencing  of  events  betw  een 
parallel  branches.  The  "iterate”  function  was  employed  to  allow  for  sequential  processing  of 
multiple  tracks  in  a  single  run  of  the  simulator.  Figure  28  shows  the  top-level  C2  operational 
activities,  arranged  in  parallel,  with  iterations  (labeled  as  "IT”  in  the  diagram)  to  allow 
representation  of  multiple  successive  tracks. 
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Figure  28:  EFFBD  of  Top-Level  C2  Operational  Activities 


This  IiFFBD  displays  !bc  top-level  operational  Activities  executed  in  parallel,  with  iteration  to 
support  successive  multiple  targets  within  a  single  run  of  the  simulation. 
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The  input  and  output  information  Hows  have  been  suppressed  in  the  figures  to  make  the 
diagrams  easier  to  read,  but  all  arc  included  and  used  in  the  simulation.  Triggers  arc  shown  in 
ovals  with  double-headed  arrow's.  All  of  the  sub-model  EFFBD  for  operational  activities  were 
created  and  arc  available  in  Appendix  I).  The  second-tier  of  the  operational  activity  model  for 
the  “Process  Targets’*  activity  is  shown  in  Figure  29.  In  this  particular  implementation  of  the 
model,  a  100%  probability  is  assigned  to  the  upper  branch  in  order  to  test  only  the  ability  to 
process  the  SUW  related  activities.  The  MIO  mission  is  represented  by  the  activity  on  the  lower 
branch.  To  toggle  between  the  mission  threads,  the  branch  probabilities  can  be  assigned  as 
100%  and  0%  or  vice  versa.  It  is  also  possible  to  assign  other  combinations  of  probabilities  to 
each  branch  (such  as  50%  and  50%),  and  to  have  both  types  of  missions  occur  within  a  single 
run  of  the  simulator.  Variations  were  tested  to  ensure  that  the  model  executes  as  expected. 
There  arc  numerous  alternative  ways  that  this  could  have  been  modeled,  including  multi-exit 
functions  that  select  the  appropriate  branch  using  control  logic  and  exceptions  logic  that  bypass 
both  of  those  options.  For  modelers  with  coding  skills,  the  CORF  scripting  language  could  also 
be  used  to  add  more  fidelity  to  the  model. 
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Figure  29:  Target  Processing  C2  Operational  Activities 


This  EFFBD  is  the  decomposition  of  the  "Process  Targets”  Operational  Activity.  The  top  branch 
includes  activities  associated  with  the  SLAV  mission.  The  bottom  branch  shows  the  activity 
associated  w  ith  MIO 


Figure  30  is  a  graphical  representation  of  the  COREsim  output  of  a  single  simulation  run.  In 
this  simulation  run.  the  C2  operational  activities  process  three  track  files,  which  represent  targets, 
arriv  ing  in  succession.  The  existence  of  a  graphical  representation  of  the  simulation  run  indicates 
that  the  simulation  executes  w  ith  no  technical  emors. 
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Figure  30:  COREsim  Results  from  C2  Operational  Activities 


Thu  figure  shows  the  CORExim  nuclei  mulls  for  litre*  targets  arriving  in  vueeenion  Each  track 
ii  processed  and  there  ore  no  errors  in  the  model 


The  operational  activity  names  arc  listed  in  the  column  on  the  left.  The  corresponding 
rectangles  on  the  right  side  of  the  diagram  indicate  blocks  of  unic  allotted  to  each  activity.  Dark 
grcen  blocks  correspond  with  activities  that  have  no  trigger,  while  the  light  green  indicates  that 
the  activity  was  triggered  by  outputs  from  another  activity.  The  yellow  indicates  a  period  of  time 
that  the  activity  is  actively  waiting  to  be  triggered.  The  boxes  with  hatching  marks  represent  the 
rolled  up  higher-level  activities.  The  decomposition  is  not  shown  fur  those  activities  that  arc 
both  continuous  and  concurrent  in  order  to  focus  attention  on  the  sequential  activities  as  they 
apply  to  each  track. 

Timing  can  be  independently  specified  for  each  activity  or  function  as  a  constant  value,  a 
probability  distribution  (a  variety  of  distri  but  ions  are  available)  or  in  accordance  with  a  CORE 
senpL  For  tins  project,  the  COREsim  model  was  used  to  verify  the  structure  of  the  architecture, 
not  In  validate  the  time-based  performance  measures  as  developed  in  the  value  system  design. 
As  a  consequence,  the  time  values  used  were  not  relevant  to  the  objectives  of  the  assessment  and 
set  solely  to  improve  the  readability  of  the  diagram. 

The  coiTesponding  EFFBDs  and  results  from  COREsim  arc  shown  for  the  SV-4  diagrams 
in  Figure  31,  Figure  32  and  Figure  33.  Figure  31  shows  the  top-level  C2  system  functions 


arranged  in  parallel  with  a  single  “iterate"  construct  to  allow  for  multiple  successive  targets.  All 
of  the  sub-model  EFFBD  for  system  functions  were  created  and  are  available  in  Appendix  D. 


Figure  31:  EFFBD  of  Top-Level  C2  System  Functions 

This  figure  shows  the  top-level  system  functions  as  an  EFFBD,  where  c»:h  function  is  executed  in 
parallel  to  .support  multiple  targets. 


Figure  32  is  focused  on  the  second-tier  of  “Conduct  Combat  Control."  where  the 
SUW  mission  is  represented  by  the  upper  branch  and  assigned  a  probability  of  100%.  while  the 
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MIO  mission  is  represented  by  the  lower  branch  and  assigned  a  probability  of  0%  (for  this 
specific  simulation  run). 


Figure  32:  Conduct  Combat  Control  C2  Functions 


Thi*  figure  show*  the  child  functions  of  the  Conduct  Combat  Control  function.  The  sepijutc 
brandies  show  the  functions  associated  with  the  SUW  and  MIO  mixtions. 


Results  of  a  simulation  run  using  just  the  SUW  mission  thread  arc  shown  in  Figure  33.  The 
graphic  shows  the  relative  sequencing  and  concurrency  of  the  ‘'Conduct  Combat  Control”  C2 
functions.  The  model  runs  without  error.  The  continuous  functions,  '‘Display  Tactical  Data”  and 
"Perform  Track  Management,”  have  been  collapsed  to  focus  on  the  details  of  the  sequential 
processing  of  each  target  in  "Conduct  Combat  Control.”  As  with  the  operational  activities 
model,  the  timing  for  each  function  could  be  adjusted  and  defined  as  either  a  constant,  a 
probability  distribution,  or  in  accordance  w  ith  a  script.  In  this  model,  the  only  adjustment  made 
to  the  default  timing  was  to  extend  the  "Wait”  time  so  that  it  is  easier  to  make  the  visual  linkage 
between  the  "Conduct  Combat  Control”  functions  and  the  associated  track  file  in  the  top  line. 

As  with  the  operational  activities,  there  is  no  basis  for  making  changes  to  the  default  constant 
value,  as  there  is  no  objective  to  validate  the  time-based  system  performance  requirements  at  this 


Figure  33:  COREsim  Results  from  C2  System  Functions 

Tlic  Huun:  ihnws  ihe  result  «f  lincc  targets  amnne  in  succcmuih  No  arm  west:  fuuntl  dunne 
cvccutiun. 

a  Results 

Within  the  limited  scope  of  the  COREsim  assessment,  no  logical  Haws  in  the  architecture 
were  identified.  The  FFFBDs  could  be  enhanced,  adding  control  functions  to  more  explicitly 
portray  decision  points,  but  these  were  not  absolutely  necessary  to  verily  the  architecture.  There 
was  value  in  the  EFFBDs,  which  prov  ided  additional  information  about  the  sequencing  of  the 
activities  and  functions.  The  process  of  developing  die  KFFBD  views  provided  greater 
understanding  of  the  architecture. 

The  full  functionality  of  COREsim  was  not  explored:  but  the  timing  capabilities  could 
possibly  be  used  in  the  context  of  the  larger  weapon  system,  supporting  tradeoff  decisions 
between  C2  and  engagement  system  time  allocations  and  using  the  threat  assessment  results  to 
bound  the  problem  space.  The  results  of  timing  studies  could  assist  in  identification  of  the 
specific  physical  implementation  of  the  system.  Also  not  used  was  the  resource  constraint 
capability  in  COREsim.  This  is  also  useful  when  evaluating  engagement  systems,  as  there  arc 
always  constraints  on  resources  such  as  ammunition.  The  constraint  requirements  developed  for 


this  project  were  enterprise-level  constraints  that  were  not  directly  applicable  to  the  C2  system 
modeling  of  a  specific  tactical  engagement. 

CORESim  requires  the  use  of  parallel  branching,  iterations,  loops  and  triggers  to 
approximate  the  concurrency  inherent  in  the  IDEFO  diagrams.  Due  to  the  complexity  of  these 
changes,  the  CORESim  assessment  was  focused  on  a  small  segment  of  the  architecture.  To  till  in 
these  gaps,  and  more  thoroughly  assess  the  logical  consistency  of  the  architecture.  CPN 
modeling  was  used. 

2.  Architecture  Verification  Using  Colored  Petri  Nets 
a.  Colored  Petri  AW  Background 

The  CPN  language  was  developed  specifically  for  the  purpose  of  modeling  and 
verification  of  concurrent,  distributed  sy  stems.  A  CPN  model  represents  the  states  of  a  system 
and  the  events  that  may  cause  the  system  to  change  state  [Jensen.  2009 1.  Due  to  the  way  CPNs 
arc  specified,  models  can  be  simulated  or  assessed  logically  through  a  state  space  analysis. 

The  CPN  modeling  language  consists  of  three  elements:  places,  transitions,  and  arcs. 
Places  represent  data  that  is  available  within  the  system  and  is  specified  by  a  color,  better  known 
as  a  data  type.  Transitions  arc  processes  that  take  data  from  places,  convert  that  data  and  send 
output  data  to  other  places.  Transitions  arc  specified  by  a  guard  condition  that  limits  data  that 
can  be  accepted  by  the  transition  and  by  the  transition's  code  segment,  winch  defines  how'  input 
data  is  processed.  Arcs  define  the  paths,  from  places  to  transitions  and  transitions  to  places, 
which  the  data  may  follow  [Jensen.  2009).  To  provide  a  parallel  to  the  SV-4  System 
Functionality  Description  in  DoDAF.  a  transition  is  equivalent  to  a  system  function  while  an  arc- 
placc-arc  combination  is  equivalent  to  a  data  (low  (an  example  is  shown  in  Figure  34). 
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Figure  34:  Example  Mapping  of  IDKFO  to  CPN 


The  figure  shows  the  mapping  of  an  IDEFO  diagram  to  a  CPN.  A  function  in  I DEJO  maps  to  a 
transition  in  CPN,  while  a  data  flow  in  IDEFO  maps  to  a  arc  place  -are  sequence  in  CPN. 


Two  other  concepts  are  important  to  understanding  how  the  CPN  language  works.  The 
first  is  the  notion  of  a  token.  During  the  execution  of  a  CPN  model,  a  token  represents  the  actual 
instantiation  of  a  data  element  in  the  model.  For  example,  a  token  in  the  C2  system  architecture 
would  be  an  instantiation  of  a  track  tile  during  execution.  A  marking  is  simply  the  set  of  tokens 
at  all  of  the  places  in  the  C  PN  model  at  a  point  in  time  during  the  model’s  execution.  A  marking 
defines  the  state  of  the  CPN  model  (Jensen.  2009]. 

CPN  Tools  was  used  to  develop  the  C  PN  model  and  to  conduct  all  of  the  verification 
activities.  CPN  Tools  is  a  freely  available  tool  developed  by  the  University  of  Aarhus  in 
Denmark.  CPN  Tools  has  an  intuitive  Graphical  User  Interface  and  allows  for  specification  of 
guard  constraints  and  code  segments  using  the  C  PN  Markup  Language,  which  is  based  on 
Standard  Markup  Language  (Jensen.  2009|. 


b.  Modeling  Assumptions 


Several  assumptions  on  the  scope  of  the  verification  effort  were  made.  Of  highest 
importance,  only  the  functional  architecture  (SV-4)  was  verified.  Due  to  the  mapping  of  the  SV- 
4  System  Functionality  Description  to  the  OV-5  Operational  Activity  Model,  in  the  SV-5,  no 
significant  benefit  would  be  achieved  from  a  separate  verification  of  the  activity  model. 

The  verification  effort  included  only  the  target  processing  components.  As  a 
consequence,  planning  and  display  functions  were  not  included  in  the  verification.  This  includes 
the  functions  M1  Display  Tactical  Data”,  "3.6  Develop  Execution  Guidance”,  and  their 
desccndents.  The  rationale  for  this  scoping  decision  was  to  exclude  functions  that  provided  a 
persistent  input  to  the  track  processing  functions,  namely  the  planning  functions,  or  did  not  have 
a  fccdhack  into  the  track  processing  functionality,  specifically  the  display  functions. 

Similarly,  external  entities  were  modeled  only  if  the  architecture  included  a  direct  output- 
input  relationship  with  the  external  entity  that  affected  target  processing.  For  practical  purposes, 
this  limited  the  external  entities  that  were  included  to  commercial  ships,  which  receive  queries 
from  the  C2  system  and  return  a  query  response. 

In  order  to  keep  the  verification  effort  to  a  manageable  size  while  still  being  able  to 
assess  the  key  elements  of  the  architecture,  verification  was  done  using  two  concurrent  targets, 
one  commercial  and  one  non-commercial.  This  allowed  the  verification  effort  to  assess  the 
proper  concurrent  execution  of  the  SUW  and  MIO  missions  and  to  assess  how  well  the 
architecture  handles  multiple,  simultaneous  targets. 

The  SV-4  was  represented  exactly  as  it  appears  in  the  architecture  with  only  a  single 
exception.  The  "Store  and  Report  Tracks”  function  was  implemented  as  a  persistent  data  store  in 
the  CPN  model.  In  the  architecture,  the  "Store  and  Report  Tracks”  function  serves  the  larger 
purpose  of  reporting  track  data  to  external  command  entities.  However,  as  described  above,  that 
portion  of  the  function  is  not  within  the  scope  of  the  verification,  only  the  data  store  component 
remained.  Figure  35  shows  how  the  "Store  and  Report  Tracks"  function  is  implemented  in  the 
System  Functionality  Description  and  how  it  is  implemented  in  the  CPN  model. 
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Figure  35:  Depiction  of  "Store  and  Report  Tracks"  function  in  SV-4  and 
CPN  models 

The  figure  show*  bow  the  "Store  and  Report  Tracks"  furxlion  is  implemented  in  the  SV-4  is  a 
function  and  as  a  place  m  the  CPN  model.  In  the  CPN  model,  the  “Sion:  and  Report  Tracks" 
function  is  replaced  by  a  "Track  Files"  place  that  serves  as  a  track  data  store  for  other  tiinclions. 

c  Verification  Techniques 

Two  separate  approaches  were  used  during  the  verification  of  the  architecture.  First, 
simulation  of  the  CPN  model  was  used  to  initially  assess  whether  the  architecture  executed 
properly.  This  technique  used  a  step-by-step  evaluation  of  the  CPN  model's  execution  to  ensure 
that  the  commercial  and  non-commercial  threats  were  handled  properly  and  that  the  model 
consistently  terminated  with  both  targets  processed.  The  CPN  approach  has  the  unique 
advantage  over  the  use  of  COREsim  in  that  the  architecture  can  be  assessed  in  its  1DEF0  form 
and  does  not  need  to  be  converted  into  an  EFFBD  to  support  simulation. 

The  second  verification  approach  was  a  state  space  analysis.  The  advantage  of  a  state 
space  analysis  over  a  simpler  simulation-based  assessment  is  that  the  state  space  analysis  cheeks 
all  possible  states  that  the  model  may  assume.  This  gives  the  state  space  analysis  the  ability  to 
identify  logical  Haws  that  may  not  manifest  themselves  during  the  execution  of  a  finite  number 
of  simulation  runs. 
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The  state  space  analysis  employs  several  distinct  checks.  The  full  state  space,  consisting 
of  all  possible  markings  of  the  system,  is  calculated.  Based  on  the  state  space,  three  assessments 
arc  made:  the  Strongly  Connected  Components  (SCC)  graph  is  calculated,  the  home  and  dead 
markings  arc  determined  and  any  live  or  dead  transitions  arc  recorded.  Kach  assessment  is 
discussed  in  more  detail  below. 

Two  markings  are  in  the  SCC-graph  if  and  only  if  they  arc  mutually  reachable.  This 
means  that  a  finite  occurrence  sequence  exists  between  the  markings.  A  SCC-graph  that  is 
smaller  than  the  full  State  Space  indicates  the  presence  of  cycles  (infinite  occurrence  sequences) 
in  the  model  (Jensen.  2009).  An  infinite  occurrence  sequence  in  the  model  implies  that  it  is 
possible  that  the  model  will  never  "finish"  or  reach  a  maricing  where  there  arc  no  enabled 
transitions.  If  the  architecture  is  correctly  designed,  the  SCC-graph  will  be  the  same  as  the  full 
State  Space.  Figure  36  gives  an  example  of  a  SCC-Ciraph  that  is  not  the  full  state  space. 


Figure  36:  Example  of  SCC-graph  that  is  a  subset  of  the  state  space 

Note  that  the  nuHtinu^  in  the  SCC* graph  cannot  b:  rorhed  from  the  markings  outsxlc  the  SCC- 
graph.  If  the  maritmg*  outside  the  SCC'  graph  arc  reached,  the  inixlcl  will  never  “finish". 

The  home  markings  and  dead  markings  provide  valuable  information  about  the  states  in 
which  the  architecture  has  terminated.  The  home  markings  can  be  reached  from  any  marking, 
meaning  that  from  any  possible  marking  of  the  system,  the  home  marking  can  be  subsequently 
reached.  For  our  architecture,  the  marking  where  all  targets  have  been  processed  should  be 
reachable  from  any  other  marking  and  thus  should  be  a  home  marking.  The  dead  markings  arc 
states  where  no  transition  is  enabled  (Jensen.  2009].  This  equates  to  the  states  where  the 


architecture  has  “finished’'.  If  the  architecture  is  correctly  defined,  the  only  dead  markings 
should  be  the  marking  where  all  targets  have  been  processed. 

Finally,  the  live  and  dead  transitions  provide  some  additional  information  about  the 
model.  A  live  transition  is  any  transition  where  an  occurrence  sequence  exists  from  every 
reachable  marking  that  contains  the  transition.  Note  that  a  live  transition  cannot  exist  if  a  dead 
marking  exists.  A  dead  transition  is  a  transition  where  no  reachable  markings  exist  where  the 
transition  is  enabled  (Jensen.  2009 1.  Essentially,  the  transition  can  never  execute.  For  a 
correctly  defined  architecture,  neither  live  nor  dead  transitions  should  exist. 

d.  Results 

Dunng  the  simulation  verification,  ten  runs  were  observed  in  step-wise  execution  without 
observed  error.  All  runs  terminated  in  the  marking  with  all  targets  processed.  The  state  space 
analysis  also  verified  the  architecture’s  logical  structure.  The  SCC-graph  showed  that  the  model 
has  no  infinite  occurrence  sequences.  Additionally,  the  home  marking  and  dead  markings  were 
identified  and  both  correspond  to  the  state  with  all  targets  processed.  This  means  that  the  state 
with  all  targets  processed  is  the  only  state  reachable  from  all  reachable  markings  and  is  the  only 
state  where  no  transitions  are  enabled  (where  the  model  is  “finished”). 

Since  the  state  with  all  targets  processed  was  identified  as  the  sole  dead  marking,  no  live 
transitions  exist.  As  well,  no  dead  transitions  were  identified.  Thus,  there  arc  no  functions  in  the 
architecture  that  can  never  be  executed. 

In  conclusion,  the  C’PN  verification  results  confirm  that  the  architecture  is  logically 
complete  and  internally  consistent.  The  architecture,  as  it  is  defined,  has  no  infinite  loops  that 
prevent  the  successful  processing  of  targets  and  will  terminate  only  in  the  state  where  all  targets 
have  been  processed. 


B.  COST  ANALYSIS 
1.  Background 

As  previously  discussed,  and  will  be  shown  below,  the  architecture  provided  inputs  to  the 
basis  of  the  cost  analysis  task.  The  Cost  Analysis  task  was  conducted  in  parallel  with  the  M&S 
task  under  the  assumption  that  the  tasks  were  independent  of  each  other.  The  Cost  Analysis  task 
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determined  that  in  today's  surface  fleet,  each  major  C2  system  has  its  own  unique  training 
pipeline  and  capability  upgrade  activities  that  are  part  of  the  life  cycle  costs.  Though  they  may 
have  common  missions,  the  C2  system  functions,  modes,  and  operator  displays  arc  different, 
requiring  distinct  training  activities  for  each  system.  To  field  a  capability  upgrade  across  C2 
systems,  the  upgrade  is  developed  and  tested  for  each  C2  system,  incurnng  costs  for  essentially 
the  same  work  multiple  times.  Using  a  common  C2  architecture  across  multiple  platfomis  has 
the  potential  of  avoiding  the  distinct  training  activity  costs  and  repetitive  costs  for  upgrade 
development.  Cost  analysis  was  conducted  to  test  the  surface  navy  acquisition  community's 
assumption  that  a  common  C2  architecture  and  set  of  requirements  would  lead  to  systems  that 
arc  less  costly  in  terms  of  operator  training  and  system  capability  upgrades  and  to  quantify  the 
potential  savings. 

2.  Methodology 

a.  Historical  Cost  Data 

Initially,  much  effort  was  expended  trying  to  obtain  actual  dollar  cost  values  from  DoD 
finance  sources  such  as  the  Defense  Cost  and  Resource  Center  maintained  by  the  Office  of  the 
Secretary  of  Defense,  the  Navy  Visibility  and  Management  of  Operating  and  Support  Costs 
(VAMOSC)  database,  and  Navy  Budget  Reports  from  the  Assistant  Secretary  of  the  Navy's 
Financial  Management  and  Comptroller  site.  However,  these  sources  generally  do  not  provide 
cost  information  decomposed  to  the  C2  system  level.  For  instance,  the  Defense  Cost  and 
Resource  Center  production  costs  arc  provided  at  the  ship  level.  VAMOSC  lists  annual  training 
costs  for  both  Aegis  and  SSDS.  but  the  costs  arc  not  decomposed  to  the  specific  C2  subsystem 
level.  Navy  Budget  Reports  list  FY08  costs  for  specific  capability  upgrades  for  both  Aegis  and 
SSDS.  but  none  arc  purely  C2  upgrades.  Without  historical  cost  data  at  the  C2  level,  a 
meaningful  parametric  cost  estimation  relationship  cannot  be  derived  (Anderson.  20K)X). 

b.  Training  Hours 

Due  to  the  lack  of  useable  detailed  data  produced  from  this  initial  effort,  the  focus  of  the 
cost  analysis  was  shifted  to  obtaining  Aegis  and  SSDS  training  hours  for  the  specific  warfare 
area  functions  defined  in  the  common  C2  architecture.  Hours  spent  training  were  used  as  a  cost 
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metric  instead  of  dollars.  Aegis  and  SSDS  C2  subsystem  training  hours  were  obtained  from  the 
Center  for  Surface  Combat  Systems  <CSCS).  which  serves  as  the  training  site  for  both  Aegis  and 
SSDS  operators  [ Parker  and  Salunga.  2009 1.  These  metrics  were  traced  directly  back  to  the 
common  C2  architecture  by  identifying  the  specific  training  cources  and  hours  that  cover  the 
specific  mission  area  C2  functions.  Surface  Warfare  functions  covered  in  both  Aegis  and  SSDS 
curriculums  of  instructions  were  candidates  for  cost  avoidance.  The  Navy  could  potentially 
condense  these  courses.  thereby  reducing  the  number  of  courses  required,  the  number  of 
instiuctore  hours  required,  and  the  amount  of  training  material  preparation  needed,  resulting  in 
more  affordable  training. 

The  seven-week  Aegis  C  ombat  System  Officer  Track  II  course  and  the  seven-week  SSDS 
Combat  System  Officer  course  contain  the  majority  of  the  surface  warfare  area  mission  training 
requirements  |Parkcr  and  Salunga.  2009).  Curricula  of  instruction  were  obtained  for  both 
training  courses  from  CSCS  (Aegis  Training  and  Readiness  Center,  2009).  Aegis  and  SSDS 
subject  matter  experts  provided  assistance  with  course  content  where  the  Navy  currently  teaches 
subjects  related  to  the  surface  warfare  mission  area  functionality  identified  in  the  project 
architecture.  The  CSCS  then  provided  calendars  for  each  course  that  indicated  the  number  of 
instiuction  hours  planned  per  curriculum  item.  The  number  of  instruction  hours  for  the  portions 
of  the  curriculum  of  interest  was  extracted  from  the  calendars.  Table  10  shows  the  results  of  the 
analysis.  The  columns  indicate  the  functions  of  the  C2  architecture  created  in  this  report  and  the 
rows  identity  the  curriculum  items.  The  intersecting  cells  indicate  the  number  of  hours  of 
instruction  for  each  function  of  the  architecture.  Curriculum  items  not  related  to  surface  warfare 
or  the  C2  architecture  were  not  included  in  this  analysis.  An  empty  cell  indicates  no  training  of 
this  function  occurc  in  this  curriculum  item.  The  training  hours  extracted  from  the  calendars  for 
each  curriculum  item  arc  shown  in  the  far  right  hand  column.  The  hours  were  distributed  evenly 
to  the  relevant  intersecting  cells  as  an  estimate  of  the  instruction  hours  per  function.  Total 
instruction  hours  per  C2  function  were  calculated  for  each  course.  The  bottom  row  shows  the 
smaller  of  the  Aegis  and  SSDS  training  hours  per  function  and  represents  the  potential  training 
hours  that  could  be  saved  if  these  C2  systems  had  a  common  architecture  for  surface  warfare 
mission  functions. 
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Table  10:  C2  Training  Hours 

Thu  tabic  shows  the  C2  training  liours  from  the  Aegis  and  SSDS  Combat  Systems  Ofliccr  courses  allocated  to  the  common  architecture 
lunetiom  The  fraurt  orr  function  arc  totaled  and  compared  to  determine  potential  duplicative  training  hours 


c  Capability  Upgrades 


System  complexity  was  investigated  as  a  comparative  measure  of  cost  for  a  C2  system 
capability  upgrade.  System  interface  information  could  be  used  to  determine  the  complexity  of  a 
system.  As  an  indicator  for  system  complexity,  the  number  of  interfaces  a  system  has,  or  the 
number  of  message  types  a  system  passes  across  an  interface,  could  provide  quantitative  values 
to  compare  across  different  systems.  In  theory,  the  more  complex  the  system,  the  more  costly  it 
would  be  to  update  |  Turney.  2000). 

This  type  of  information  could  be  used  to  assess  the  level  of  complexity  of  a  system. 
With  access  to  system  interface  documents,  interface  variables  such  as  quantity  of  interfaces  and 
quantity  of  message  types  across  each  interface  could  be  used  as  values  to  compare  the  relative 
complexity  between  multiple  systems.  A  thorough,  quantitative  analysis  of  this  kind  of 
information  requires  access  to  some  classified  sources  for  a  complete  definition  of  all  interfaces. 
In  order  to  keep  the  report  unclassified,  the  complexity  versus  upgrade  cost  aspect  was  not 
pursued.. 


3.  Cost  Analysis  Conclusions 

Table  10  shows  a  total  of  fi fly-nine  training  hours  from  both  the  Aegis  and  SSDS 
curriculum  that  could  potentially  be  condensed  if  a  common  C2  system  for  surface  warfare  was 
used.  Fifty-nine  hours  is  25%  of  the  total  (including  non  C2)  instructional  hours  from  each 
course.  From  a  future  C2  system  perspective,  this  is  a  potential  cost  avoidance  of  fifty-nine 
training  hours  m  the  surface  warfare  mission  alone  by  using  a  common  C2  system  across 
platforms. 

Note  this  data  shows  no  common  hours  for  the  MIO  unique  functions  Quay  Ship  and 
Issue  Boarding  Order.  MIO  is  not  part  of  the  Aegis  Combat  System  Officer  couise.  nor  is  MIO 
part  of  the  Aegis  curriculum  at  CSCS  (Parker  and  Salunga.  2009|.  One  recommendation  for 
further  study  (using  the  same  training  hour  metric!  would  be  to  explore  other  warfare  areas 
including  MIO.  It  is  also  quite  possible  that  additional  surface  warfare  training  hours  would  be 
considered  common.  This  analysis  only  considered  one  course  for  each  C2  system  that  the 
CSCS  staff  considered  to  contain  the  majority  ofC2  training.  Broadening  this  approach  to  other 
mission  areas  could  support  the  general  notion  that  a  mission  driven  system  functional 
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architecture  will  result  in  functionality  across  systems  that  would  be  similar  as  to  ease  the 
training  requirements  across  systems. 

This  cost  analysis  supports  the  surface  navy  acquisition  community's  assumption  that  a 
common  C2  system  will  reduce  the  cost  of  training.  However,  due  to  the  lack  of  open  source 
information  on  Aegis  and  SSDS  C2  interfaces  and  message  types,  a  conclusion  on  the 
assumption  that  common  C2  would  reduce  the  cost  of  capability  upgrades  could  not  be  reached. 
A  second  recommendation  for  further  study  is  to  examine  the  availability  of  the  interface 
information  and  the  validity  of  using  interface  complexity  as  a  cost  metric. 


95 


THIS  PAGE  INTENTIONALLY  LEFT  BLANK 


96 


V.  SUMMARY  AND  AREAS  FOR  FURTHER  STUDY 


A.  SUMMARY 

The  objective  of  this  report  was  to  test  the  assertion  that  a  common  architecture  would 
reduce  combat  system  lifecycle  costs.  The  project  used  a  three  phase  Systems  Engineering 
model  (Figure  37)  to  gather  stakeholder  inputs,  develop  a  common  architecture,  and  then 
investigate  if  the  common  architecture  can  support  training  cost  savings.  The  products  from 
each  successive  phase  served  as  inputs  for  the  follow-on  phases. 

Through  this  process,  a  common  architecture  for  a  generic  naval  warship  C2  system  was 
developed,  using  two  mission  threads.  SUW  and  MIC),  as  a  basis  for  the  functionality  of  the 
system.  The  system  functionality  identified  in  the  architecture  was  used  to  identify  course 
material  from  two  current  combat  systems  that  could  be  combined  if  a  combat  system  was 
developed  using  a  common  architecture.  The  cost  analysis  findings  indicate  that  potential 
savings  in  training  hours  could  be  realized  if  a  common  architecture  were  to  be  developed. 

There  were  three  steps  in  the  Needs  Analysis  Phase:  Stakeholder  Analysis  proved  to  be 
the  foundational  step  in  clarifying  the  problem  statement.  Primarily  through  review  of  joint  and 
naval  service  doctrine,  this  step  revealed  a  conceptual  functionality  of  the  purpose  of  a  C2 
system  and  desired  characteristics  of  a  C2  system.  Another  important  concept  gained  during  this 
step  was  that  a  C2  system  includes  software,  hardware,  and  people.  This  concept  was  a  key 
contributor  leading  into  the  mission  thread  development.  The  stakeholder  interviews  conducted 
during  this  step  validated  some  of  the  information  gathered  in  the  document  review',  giving  the 
analysis  a  “real  person”  perspective. 

The  purpose  of  the  threat  assessment  was  to  gain  an  understanding  of  the  types  of  vessels, 
and  their  threat  characteristics,  that  the  C2  system  might  encounter.  Extensive  open  source 
research  was  conducted  in  this  area  and  the  results  of  the  research  contributed  to  C2 
requirements  development  and  analysis.  The  threat  assessment  could  also  be  valuable  in 
defining  sensor  characteristics  such  as  range,  search  rate,  and  resolution.  However  sensor 
systems  and  specific  timing  requirements  were  beyond  the  scope  of  the  project. 
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Figure  37:  Summary  of  Project  Systems  Engineering  Process 

This  Figure  uinumri/cs  the  three  phase  systems  engineering  pnxes*  used  to  develop  the 
enterprise  architecture  arc!  to  estimate  potential  cost  savings  achieved  by  using  a  common 
architecture  Outputs  from  each  phase  provided  inputs  to  follcnv -on  phases. 

Like  the  Stakeholder  Analysts,  the  Mission  Thread  definition  also  provided  foundational 
information  for  the  project.  Two  mission  threads  built  upon  the  information  gathered  in  the 
Stakeholder  Analysis.  This  step  translated  the  high  level  concepts  into  a  more  detailed  level  of 
activities  and  interactions,  which  were  then  used  to  support  requirements  and  architecture 
development.  Another  key  aspect  of  this  step  was  problem  scoping.  The  mission  threads 
delineated  what  was  inside  the  system  boundaries,  and  what  was  outside  the  system  boundaries. 
For  example,  sensor  characteristics  were  outside  of  the  system  boundary,  as  discussed  above. 
People,  on  the  other  hand,  as  it  was  learned  during  the  Stakeholder  analysis,  were  inside  the 
system  boundary. 


The  next  phase.  Functional  Analysis,  included  three  steps:  Requirements  Definition. 
Value  System  Design,  and  Enterprise  Architecture.  The  Requirements  Definition  produced 
written  statements  to  describe  the  characteristics  of  the  C2  system.  This  step  was  the  link 
between  the  concepts  in  the  Needs  Analysis  and  the  system  functionality  depicted  in  the 
architecture.  This  step  provided  the  quality  control  that  the  functions  in  the  architecture  comectly 
supported  the  concepts  of  the  Needs  Analysis  phase.  Through  traceability  from  the  Needs 
Analysis  concepts  to  the  functions  documented  in  the  architecture,  the  requirements  definition 
step  ensured  that  the  needs  analysis  concepts  were  being  addressed  and  also  that  the  architecture 
did  not  include  unnecessary  functions. 

The  Value  System  Design  identified  quantitative  values  or  ranges  that  were  included  as 
attributes  of  the  requirements.  These  values  would  be  useful  during  design  and  development 
when  the  systems  are  actually  being  built;  defining  how  well  the  systems  need  to  perform.  The 
values  also  provide  a  benchmark  during  testing,  as  a  measure  of  how  well  the  system  performs. 
However,  the  contributions  of  the  Value  System  Design  step  was  negligible  for  the  scope  of  this 
project,  which  was  the  high  level  definition  of  requirements  and  architecture  to  support  training 
cost  evaluation. 

The  Enterprise  Architecture  step  described  the  functionality  and  interactions  of  the  C2 
system,  working  within  the  boundaries  established  by  the  mission  threads  and  the  requirements. 
The  architecture  further  described  the  functionality  of  the  system,  and  also  how  the  functions 
would  interact  with  each  other.  A  key  objective  of  this  step  was  to  describe  the  functionality  of 
the  system.  This  system  functionality  was  then  used  in  the  development  of  the  end  state  of  this 
project  -  the  training  cost  analysis. 

The  final  phase  of  the  project  was  Modeling  and  Analysis.  This  phase  included  two 
unrelated  steps,  validation  of  the  architecture  and  cost  analysis.  Since  both  steps  involve 
modeling  and  analysis,  they  were  included  in  the  same  phase.  However,  there  is  risk  that  the 
independent  steps  are  misinterpreted  as  being  dependent  upon  each  other.  Hie  puiposc  of  the 
Modeling  and  Simulation  step  was  to  validate  that  the  functions  in  the  architecture  were 
organized  in  a  logical  and  executable  manner:  for  example  an  architecture  that  classifies  a 
contact  before  it  detects  it  would  not  be  realistic  or  executable.  The  model  and  simulation  step 
validated  that  the  organization  of  the  functional  architecture  was  reasonable. 
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The  Cost  Analysis  step  provided  the  end  product  for  this  project  -  an  assessment  of 
whether  an  enterprise  architecture  could  result  in  training  cost  savings.  The  step  used  a  matrix  to 
compare  the  functions  in  the  project  architecture  to  known  topics  being  taught  tn  current, 
independent  C2  system  courses.  The  unions  between  functions  and  course  topics  identified 
potential  areas  of  overlap  for  the  two  training  courses  evaluated.  The  project  used  course  hours 
as  the  comparison  metric.  Actual  dollar  cost  was  considered  as  a  metric  option  but  rejected 
because  of  the  greater  amount  of  variability  associated  with  training  costs.  Training  hours  was 
considered  to  be  a  more  metric  for  comparison.  The  analysis  concludes  that  the  design  of  a 
common  C2  system,  derived  from  an  enterprise  C2  architecture  could  support  training  cost 
savings. 

Overall,  the  project  team  learned  that  it  is  possible  to  design  a  functional  architecture 
based  upon  some  high-level  concepts  and  needs.  It  is  critically  important  to  conduct  research  in 
order  to  understand  stakeholder  needs.  Written  requirements  add  clarity  and  definition  to  the 
initial  problem  concept.  Architecture  products  add  fidelity  and  increase  the  understanding  of  the 
initial  need.  The  systems  engineering  process  used  in  this  project  does  help  move  the  Navy 
towards  an  enterprise  architecture  approach  to  achieve  cost  savings. 

B.  AREAS  FOR  FURTHER  STUDY 

This  report  acknowledges  the  limited  scope  of  this  project.  Areas  for  further  study  were 
identified  throughout  the  development  of  this  study  and  arc  summarized  below. 

•  Further  mature  the  requirements  and  architecture  developed  in  this  report: 
Using  the  process  identified  in  this  report,  work  could  be  continued  to  add  to  the 
fidelity  of  the  existing  requirements  and  architecture  set.  Additional  requirements 
and  architecture  products  could  be  developed.  Quantitative  values  could  be  refined 
and  added  to  the  requirements.  These  same  quantitative  values  could  then  be 
incoiporatcd  into  the  architecture  and  performance  tested. 

•  Expand  the  architecture  to  additional  mission  areas:  Additional  mission  threads 
could  be  developed  (for  example,  conduct  air  warfare).  Associated  requirements  and 
architecture  products  could  then  be  developed  and  added  to  these  existing  products. 

•  Conduct  additional  cost  analysis:  Cost  analysis  in  the  training  area  could  be 
expanded  in  several  ways,  including:  investigation  of  additional  training  methods. 
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adding  actual  cost  values  to  the  existing  metrics  identified  in  this  report,  and 
investigating  training  hours  for  additional  mission  areas.  Other  areas  for  further  study 
include  the  investigation  of  additional  cost  metrics,  maintainer  documents,  spare 
parts,  logistics  infrastructure  and  capability  upgrade  comparisons. 
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APPENDIX  A:  PROGRAM  MANAGEMENT  PLAN 


INTRODUCTION 

This  is  the  project  management  plan  (PMP)  lor  the  Naval  Postgraduate  School  (NPS)  Masters  of 
Science  in  Systems  Engineering  (MSSE)  program  capstone  project  Cohort  31 1-074.  The  PMP 
was  prepared  by  the  Naval  Surface  Warfare  Center  (NSWC)  Corona  Division  and  Dahlgrcn 
Division  team.  The  project  is  an  enterprise  requirements  and  architecture  (ER&A)  initiative. 

Problem  Statement 

Across  the  Surface  Navy  Enterprise,  each  new  ship  class  implements  a  new  command  and 
control  (C2)  design  for  the  combat  system  with  a  unique  set  of  system  requirements  and 
associated  architecture.  This  leads  to  individual  platform  development  efforts,  operations  and 
support  requirements,  and  training  pipelines  which  complicates  interoperability  and  incun> 
additional  costs  to  the  Navy.  There  is  a  need  to  define  a  superset  of  requirements  and  a  common 
enterprise  command  and  control  architecture  that  can  be  implemented  by  multiple  surface  ship 
platforms.  A  single  architecture,  defining  the  functionality  required  and  allocating  those 
functions  to  system  elements,  would  allow'  for  a  concept  of  modular  sensor  and  weapon  interface 
elements.  If  the  architecture  is  reusable  and  scalable  to  future  ship  classes,  a  potential  for 
lifecycle  cost  savings  exists. 

Project  Proposal 

Surface  combatant  platforms  commonly  have  battlespacc  awareness  as  well  as  command  and 
control  (C2)  for  core  ship  self-defense  and  area-defense  missions  in  the  area  of  surface  warfare 
(SUW).  The  NSWC  team  will  use  Department  of  Defense  Architecture  Framework  (DoDAF) 
products  to  define  an  cnteipnsc-levcl  C2  architecture  that  is  independent  of  existing  systems  or 
platforms.  The  architecture  developed  will  support  functionality  noimally  performed  by  guided 
missile  cruisers  (C(i),  guided  missile  destroyers  (DDG),  and  guided  missile  frigates  (FFG).  with 
the  expectation  that  the  concepts  and  processes  developed  in  this  project  can  be  scaled  to  broader 
surface  platform  applications.  The  DoDAF  products  will  be  based  upon  two  representative 
mission  threads  and  associated  C2  functionality. 
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The  NSWC  team  has  identified  two  mission  threads  to  be  assessed,  one  of  a  combat  nature  and 
one  of  a  non-combat  nature: 

•  Conduct  SUW  -  Detect,  track,  identify,  report,  support  engagement  decisions,  and 
maintain  status  on  surface  contacts. 

•  Conduct  maritime  interception  operations  (MIO)  -  Exchange  information  during  a  MIC) 
event  to  support  battlespacc  awareness  and  decision-making. 

The  above  mission  threads  will  be  addressed  in  the  architecture  and  developed  to  exercise  the 
following  C2  functionality  (DoDCCRP,  2008): 

•  Common  Tactical  Picture  (CTP) 

o  The  capability  for  all  participating  units  to  display  the  same  tactical  picture  as  the  unit 
that  detects  the  target. 

o  The  ability  to  accurately  report  contact  identification,  heading,  position,  and  speed. 

•  Common  Operational  Picture  (COP) 

o  The  ability  to  follow  a  set  doctrine  that  is  common  among  all  units. 

o  The  ability  to  accurately  report  ship  and  strike  group  status  to  higher-level  command 
organizations  and  to  receive  and  maintain  force-level  status. 

•  Tactical  C2 

o  The  ability  to  follow  the  Navy  or  Joint  Task  List  for  the  following  critical  operational 
components:  detect,  track,  identify,  report,  engage,  and  manage  data. 


104 


Risk  Management 

The  Project  Management  team  will  be  responsible  for  risk  analysis,  risk  mitigation  and  risk 
tracking.  Project  members  will  contribute  to  risk  identification.  Risk  analysis  will  follow  a 
standard  likelihood  and  consequence  assessment  and  use  the  risk  rating  matrix  in  the  Risk 
Management  Guide  for  DoD  Acquisition.  Due  to  the  constraints  of  the  academic  calendar  and 
the  absence  of  funding  for  the  effort,  all  risks  arc  to  performance.  In  other  words,  the  quality  of 
the  product  is  what  is  at  risk,  not  when  it  will  be  delivered  or  at  what  cost. 

Limited  options  exist  for  risk  mitigation  within  the  structure  of  the  Capstone  project,  therefore, 
avoidance  of  risk  may  require  a  renegotiation  of  the  PMP.  Control  of  risk  by  adding  personnel 
or  maintaining  parallel  approaches  will  be  severely  constrained  by  the  extent  of  existing  tasking. 
There  is  no  external  entity  onto  which  to  transfer  nsk.  This  makes  risk  assumption  the  default 
mitigation  approach.  If  risks  are  realized  such  that  the  NSWC  team  w  ill  not  be  able  to  satisfy  the 
PMP.  the  risk  will  be  mitigated  via  a  renegotiation  of  the  PMP  with  a  reduced  scope  in  the  nsk 
area. 


Risk  status  will  be  reported  by  the  Program  Management  team  at  each  Integrated  Product 
Review  (I PR).  If  required,  risks  will  be  reported  in  the  interim  periods  to  the  advisors  and 
project  stakeholders  by  the  Program  Management  team.  The  two  major,  initial  risks  have  been 
identified  and  assessed,  summarized  in  Table  1. 


Table  1:  Risk  Management  Matrix 


Risk 

II) 

Risk 

Name 

Description 

Likelihood 

Consequence 

Risk 

Rating 

R00I 

Com 

Analysis 

Data 

Not  all  data  required  to 
complete  the  cost  analysis 
may  be  available. 

Near 

Certainty 

<5) 

Minor  (2) 

Yellow 

R002 

Not  all  data  required  to 
complete  the  performance 
analysis  may  be  available. 

Highly 

Likely  (4) 

Moderate  (3) 

■ 
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Vision 

The  NS WC  team’s  vision  is  to  create  an  enterprise-level  C2  architecture  for  CGs.  DDGs,  and 
FFGs,  with  the  expectation  that  the  architecture  can  be  generalized  and  utilized  by  other 
platforms.  The  core  architecture  addresses  two  diverse  mission  threads,  a  combative  and  non- 
combativc  thread.  This  combination  of  threads  will  allow  the  team  to  work  through  and  identify 
several  of  the  issues  that  may  not  be  realized  through  an  otherwise  similar  mission  thread 
selection.  Ultimately,  the  enterprise  solution  developed  will  act  as  a  foundation  for  future  Navy 
application.  This  foundation  will  be  used  to  save  the  Navy  integration  lead  time,  minimize 
redundant  logistic  support  pipelines,  and  reduce  the  need  for  stovepipe  training  methods. 
Further,  this  architecture  will  lead  to  a  cross-trained  sailor  and  a  more  effective  and  unified  Fleet. 

End-Slate 

The  NSWC  team  will  develop  a  superset  of  C2  requirements  for  multiple  platforms  based  on  the 
mission  threads  to  conduct  SIJW  and  MIC).  The  team  will  develop  an  enterprise-level  C2 
architecture  and  will  provide  DoDAF  products  based  on  the  mission  threads  and  the  superset  of 
C2  requirements.  The  NSWC  team  will  perform  a  cost  analysis  to  establish  potential  cost 
differences  with  current  configurations  of  C2  architecture.  The  final  report  will  document  the 
methodology  and  the  process  used  to  identify  the  superset  of  requirements,  providing  a  traceable 
and  repeatable  means  for  developing  other  C2  architectures  for  differing  mission  threads. 

PROJECT  PARTICIPANTS 
l  eam  Members 

The  ER&A  capstone  project  team  is  composed  of  sixteen  students  enrolled  in  the  MSSE  with  a 
systems  development  focus  distance  learning  program  at  NPS  in  Monterey.  California.  The  team 
members  and  their  respective  organizations  arc  listed  in  Table  2. 
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Table  2:  NSWC  MSSE  Team  Members 


NSWC  DAHLGREN 

NSWC  CORONA 

Joanna  Bcgcr-Mason 

Elvis  Acosla 

Harry  Donovan 

Jordan  Barla 

Mall  Eak 

Llcwclynn  (ialaec 

Dave  Finley 

Andrina  Maurselh 

Brian  Jones 

Lee  Metz 

Lesley  Painchaud 

Rcshma  Such  it 

Josh  Pepper 

Rob  Tidwell 

David  Yu 

Bob  Zanella 

ream  Organization 

The  NSWC  project  team  is  organized  into  four  working  groups  (WG)  as  shown  in  Figure  1. 
Each  working  group  will  manage  specific  roles  and  responsibilities,  which  will  be  discussed  in 
detail  in  subsequent  sections.  As  a  collective,  the  working  groups  collaborate  to  form  the  NSWC 
integrated  product  team  (IPT>  to  deliver  the  final  project  report  and  presentation. 


Figure  1:  NSWC  IPT  Structure 


Roles  and  Responsibilities 

The  ER&A  effort  will  be  integrated  organizationally  to  accommodate  the  assigned  technical 
authorities  and  engineering  specialties  commensurate  with  the  requirements  of  the  project.  The 
NSWC’  team  has  identified  key  working  groups  in  an  effort  to  assign  points  of  contact  and 
accountability  for  all  major  tasks.  Working  group  personnel  and  responsibilities  are  addressed  in 
the  subsequent  section.  Figure  2  identifies  the  leads  and  members  of  the  working  groups. 
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Figure  2:  NSWC  Working  Group  Structure 


Project  Management  Working  Croup 

The  Project  Management  group  coordinates  the  overall  activities  of  the  NSWC'  project  team. 
The  project  management  working  group  consists  of  the  Project  Leaders,  Technical  Assistants 
(TAs)  Scheduler*,  and  Librarians. 


•  Project  Leader 

The  project  leader  is  responsible  for  overall  management  ot’  the  capstone  project.  There  is  a 
leader  at  each  NSWC'  site  (Dahlgrcn  and  Corona)  to  manage  and  execute  the  project 
according  to  the  project  plan  and  to  maintain  a  balance  between  the  technical,  schedule,  and 
administrative  requirements  of  the  project  and  organization  of  working  groups.  The  project 
leader  responsibilities  include:  facilitate  group  meetings  and  information  exchange,  monitor 
and  guide  the  overall  project  activities,  foster  team  member  participation,  and  promote 
collaboration  among  the  working  groups. 
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•  Librarian 


The  Librarian  is  responsible  for  cataloguing  reference  material,  tracking  and  verifying 
sources  of  research,  and  ensuring  completeness  of  references  for  project  deliverables.  The 
Librarian  will  coordinate  Blackboard  document  control  efforts  with  the  working  group 
leaders. 

•  Schedulers/Technical  Assistants  (TA) 

Schedulers.'TAs  arc  responsible  for  assisting  the  project  lead  with  administrative  tasks, 
recording  and  distributing  meeting  minutes,  scheduling  cither  KIluminatcLivc!  or  Defense 
Connect  Online  (DCO)  sessions,  maintaining  the  master  schedule  and  plan  of  action  and 
milestones  (POA&M),  and  creating  Blackboard  repositories  for  the  team’s  various 
documents. 

editorial  Working  Group 

The  purpose  for  this  working  group  is  to  ensure  that  all  deliverable  documents  comply  with  the 
SE  Writing  Standards  and  to  ensure  that  the  documents  arc  comprehensive  and  complete.  The 
editorial  WG  consists  of  an  editor-in-chief.  report  editors,  and  presentation  editors. 

•  Lditor-in-(hief 

The  primary  responsibility  of  the  cditor-in-chicf  is  to  review'  and  edit  all  deliverable 
documentation.  The  editor-in-chief  delegates  responsibilities  to  the  other  members  of  the 
editing  staff' as  necessary'.  The  editor-in-chief  will  also  w  ork  with  the  Librarian  to  ensure  that 
all  sources  have  been  cited  appropriately. 

•  Report  Editor 

The  report  editors  will  assist  the  editor-in-chief  with  the  reviewing  and  editing  of  report 
sections,  ensuring  that  the  content  is  consistent  with  the  presentation  material,  and  ensuring 
content  meets  SE  Writing  Standards  and  milestone  requirements. 
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•  Presentation  Editor 


The  presentation  editors  will  assist  the  Editor-in-chief  in  reviewing  and  editing  of 
presentations,  ensuring  that  the  content  is  consistent  with  the  report  material,  and  ensuring 
the  content  meets  SE  Writing  Standards,  milestone  requirements,  and  Integrated  Product 
Review  (IPR)  requirements. 

Requirements  Analysis  Working  Group 

The  requirements  analysis  working  group  coordinates  the  efforts  of  the  following  working 
groups:  stakeholder  analysis,  mission  thread  development,  threat  assessment,  requirements 
definition,  and  value  system  design.  Each  of  these  working  groups  w  ill  aid  in  the  formulation  of 
a  comprehensive  set  of  requirements. 

•  Stakeholder  Analysis  Working  Group 

The  stakeholder  analysis  working  group  is  responsible  for  identifying  clients  (and 
organizations)  that  will  benefit  in  the  success  of  the  HR&A  being  developed.  Analysis 
includes  identifying  the  client's  needs  and  objectives,  which  will  be  used  to  translate  into 
functional  requirements.  The  lead  will  maintain  contact  with  the  stakeholders)  and  will 
coordinate  with  the  advisors  to  solicit  information. 

•  Mission  Threads  W  orking  Group 

The  mission  threads  working  group  is  responsible  for  researching  and  establishing  the 
mission  threads  that  arc  required  for  HR&A. 

•  Threat  Assessment  Working  Group 

The  threat  assessment  working  group  is  responsible  for  conducting  an  analysis  of  threats  to 
naval  platforms  relevant  to  the  selected  mission  threads. 

•  Requirements  Definition  Working  Group 

The  requirements  definition  working  group  is  responsible  for  translating  stakeholder  needs 
and  objectives  into  HR&A  functional  requirements  and  tracing  these  requirements  to  the 
applicable  system  elements. 
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•  Value  System  Design  Working  Group 

The  value  system  design  working  group  is  responsible  for  creating  a  value  tree  (a  composite 
of  the  stakeholder  and  functional  analyses)  and  identifying  metrics,  such  as  performance 
measures.  The  lead  will  coordinate  with  the  stakeholder  analysis  and  requirements  definition 
working  groups  to  ensure  the  model  reflects  the  stakeholders'  needs  and  objectives  and 
functional  requirements  and  will  provide  the  metrics  to  the  Modeling  &  Simulation  (M&S) 
working  group. 

Architecture  Working  Croup 

The  architecture  working  group  is  responsible  for  overseeing  and  coordinating  the  development 
of  the  architecture  for  the  enterprise  requirements.  This  group  will  participate  in  preparation  of  a 
high-level  system  and  requirements  definition  and  coordinate  with  the  project  leads  and  modclcrc 
on  execution  of  all  technical  aspects  of  the  architecture.  The  architecture  group  will  also  prepare 
and  submit  an  l*R&A  integration  report  to  the  project  leads,  which  will  identify  interfaces 
between  systems,  subsystems,  and  platfomis  that  need  to  be  included  as  part  of  ER&A. 

•  Modeling  &  Simulation  Working  Group 

The  modeling  and  simulation  working  group  will  identify  M&S  tools  and  assist  other 
working  groups  in  developing  and  conducting  M&S  to  evaluate  the  effectiveness  of  the 
combat  sy  stem  command  and  control  architecture. 

•  Cost  Estimation  Working  Group 

The  cost  estimation  working  group  will  ensure  that  all  cost  categories  arc  considered  and  that 
a  cost-benefit  analysis  is  completed  for  decisions  in  the  program.  The  cost  analysis  includes 
the  evaluation  of  trade-offs  that  reduce  cost  while  still  meeting  all  operational  requirements. 

Advisors 

The  ER&A  capstone  project  lead  advisors  arc  Mr.  Gregory  Miller  and  Prof.  Paul  Montgomciy. 
faculty  members  of  the  Department  of  Systems  Engineering  at  NPS.  The  ER&A  capstone 
project  support  advisor  is  Dr.  Emmett  Maddry,  a  senior  leader  at  NSWC  Dahlgren  Division. 
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Stakeholders 

The  roles  of  the  stakeholders  will  be  to  evaluate  the  merit  of  the  project  and  provide  direction  to 
help  guide  the  development  efforts.  The  primary  activities  of  the  stakeholders  will  be  to  provide 
informal  feedback  to  the  students  throughout  the  project  and  provide  formal  feedback  by 
participating  in  the  three  project  reviews.  If  conflicting  guidance  or  objectives  arc  received  from 
stakeholders,  the  team  will  negotiate  with  the  stakeholders  to  attempt  to  achieve  a  consensus, 
(iiven  the  limited  performance  period  of  this  project,  the  team  (with  staff  advisor  concurrence) 
will  choose  a  solution  to  implement  for  the  project  and  document  the  discrepancy  of  non- 
concurrence  in  the  final  report.  At  this  time  the  NSWC  team  is  still  in  the  process  of  identifying 
stakeholders  and  thus  far,  three  stakeholders  at  NSWC  Dahlgrcn  have  been  identified,  Mr.  (iil 
(ioddin,  Mr.  Tim  Neel,  and  Mr.  Doug  Haas. 

Mr.  (iil  (ioddin  is  a  Senior  Systems  Engineer  in  the  Warfare  Systems  Department  Warfare 
Systems  Engineering  and  Analysis  Division.  He  is  the  Warfare  Systems  Definition  Branch  head 
and  is  currently  the  enterprise  Systems  Engineer  who  works  with  Program  Executive  Office 
(PEO)  Integrated  Warfare  Systems  (IWS)  to  define  commonality  across  platforms  for  combat 
system  design. 

Mr.  Tim  Neel  is  a  Senior  Combat  Control  Systems  Engineer  in  the  Warfare  Systems  Department 
Combat  Control  Division.  Mr.  Neel  has  extensive  experience  leading  C2  and  combat  system 
architecture  development  efforts.  He  is  currently  involved  in  three  distinct  C2  and  architecture 
efforts. 

Mr.  Doug  Haas  serves  as  the  Senior  Technical  Advisor  to  the  Warfare  Systems  Department 
Combat  Control  Division  and  supports  the  department  for  combat  control  systems  engineering 
matters  regarding  the  continued  advanced  development  of  surface  combatants.  He  has  a  broad 
w  orking  knowledge  of  the  architecture,  requirements,  performance,  capability  and  limitations  of 
the  individual  combat  control  systems  providing  this  functionality. 

The  NSWC  team  has  identified  three  other  potential  stakeholders  at  NSWC  Dahlgrcn;  however 
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the  team  has  not  yet  confirmed  that  these  stakeholders  will  be  able  to  participate.  The  team  will 
also  attempt  to  identify  and  engage  user  and  resource  sponsor  stakeholders. 

MANAGEMENT  PROCESS 

Systems  Engineering  Design  Process  (SEDP) 

The  NSWC  team  will  employ  a  tailored  systems  engineering  design  process  (SEDP)  illustrated 
in  Figure  3  to  establish  a  C2  enteipnse  architecture  and  requirements.  This  process  is  an 
adaptation  of  the  systems  engineering  process  published  in  System  Engineering  Fundamentals 
from  the  Defense  Acquisition  University  in  January  of  2001  was  tailored  to  reflect  the  actual 
phases  planned  for  this  Capstone  Project. 

The  process  begins  with  the  Needs  Analysis  phase,  where  the  problem  statement  is  refined  to 
understand  the  stakeholders  and  their  actual  needs  and  expectations.  This  phase  will  also 
describe  the  mission  threads  that  the  team  identified  as  part  of  the  project  proposal  and  identify 
the  threat  against  which  the  C2  architecture  and  requirements  must  perform.  These  tasks  will 
occur  in  parallel. 

The  Functional  Analysis  phase  will  define  the  system-level  requirements,  followed  by  a 
functional  architecture  for  the  C2  aspects  of  the  platfomi  and  a  value  system  design  by  which  the 
architecture  will  be  evaluated.  As  the  team  woiis  through  this  phase,  the  team  will  return  to  the 
tasks  performed  in  the  Needs  Analysis  phase  to  determine  whether  stakeholder  input  is  needed 
for  clarification,  whether  threads  arc  adequately  defined,  or  whether  threats  arc  fully  established. 

The  Modeling  and  Analysis  phase  will  provide  simulation  results  to  support  and  further  define 
the  metrics  identified  during  the  Functional  Analysis  phase.  The  team  will  also  perform  a  cost 
analysis  to  identify  potential  cost  differences  in  current  configurations.  Similar  to  the  previous 
phase,  the  team  will  re-evaluate  the  requirements,  architecture,  mission  threads,  and  threats  as 
appropriate  and  will  contact  the  stakeholders  to  determine  whether  the  project  remains  on  task 
with  the  stakeholders’  needs.  This  project  will  result  in  a  documented  process  for  developing  a 
scalable  enterprise  requirements  and  architecture  set.  as  well  as  specific  requirements  and 
architecture  sets  to  support  the  identified  project  mission  threads.  The  following  sections  specify 
the  tasks,  input  and  output,  and  tools  required  for  the  NSWC*  team  to  pcrfoim  the  defined  tasks. 
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Figure  3:  NSWC  Tailored  Waterfall  Process 


Needs  Analysis  Phase 
•  Task  I  Stakeholder  Analysis 

This  task  will  identify  the  applicable  stakeholders,  identify  key  stakeholder  guidance,  and 
identify  the  guiding  principles  for  further  needs  analysis.  Stakeholder  guidance  includes 
strategy  documents,  doctrinal  publications,  tactical  publications,  and  tactical  task  lists. 

Inputs:  Problem  statements 

Tools:  Publication  review,  interviews  with  stakeholders 

Outputs:  Description  of  stakeholder  needs  and  guidance,  desired  measures  to  be 

used  in  Value  System  Design  phase 
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•  Task  2  Mission  Thread  Definition 


This  task  will  research  and  establish  the  mission  threads  that  arc  required  for  ER&A.  This 
task  will  define  the  details  of  the  SUW  and  MIO  mission  threads. 

Inputs:  Problem  statements,  stakeholder  analysis.  Navy  doctrine  and  publications, 

mission  thread  identification 

Tools:  Affinity  diagrams,  research,  mission  threads,  context  level  extended 

functional  flow  block  diagrams  (EFFBDs) 

Outputs:  Mission  thread  definition,  context  diagram 

•  Task  3  Threat  Assessment 

This  task  will  identify  the  potential  threats  to  U.S.  Navy  platforms  during  the  conduct  of 
SUW  and  MIO  missions  across  the  spectrum  of  operating  areas  and  conventional  and  non- 
convcntional  threat  systems. 

Inputs:  Problem  statement,  stakeholder  analysis,  mission  thread  definition 

Tools:  Research 

Outputs:  Threat  assessment 

Functional  Analysis  Phase 

•  Task  I  Requirements  Definition 

This  task  will  translate  stakeholder  needs  and  objectives  into  ER&A  functional  requirements 
and  decompose  these  requirements  into  a  functional  architecture. 

Inputs:  Stakeholder  analysis,  mission  thread  definition,  threat  assessment,  context 

diagram 

Tools:  CORE 

Outputs:  Initial  requirements  hierarchy,  functional  hierarchy,  operational  activity 

diagram  (OV-5),  enterprise  requirements,  requirements  traceability 

•  Task  2  Enterprise  Architecture 

This  task  will  produce  the  enterprise  architecture  for  the  combat  system. 

Inputs:  Enterprise  requirements 

Tools:  CORE 

Outputs:  Enterprise  architecture 

•  Task  3  V  alue  System  Design 
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This  task  will  produce  a  value  tree,  which  decomposes  the  architecture  down  to  applicable 
functional  levels.  This  task  will  identify  metrics,  such  as  pcrfoimancc  measures. 

Inputs:  Enterprise  requirements  and  architecture 

Tools:  CORE 

Outputs:  Metrics  and  threshold  values 

Modeling  and  Analysis  Phase 

•  Task  1  Modeling  and  Simulation 

This  task  will  produce  models  to  simulate  the  architecture  requirements  and  to  validate  the 
architecture  developed  in  the  previous  phases.  This  task  will  also  provide  input  to  the  cost 
analysis. 

Inputs:  Value  system  design,  enterprise  architecture  and  requirements 

Tools:  CORE,  Arena,  Microsoft  Excel 

Outputs:  Simulation  output  and  description 

•  Task  2  Cost  Analysis 

This  task  will  explore  life  cycle  costs  associated  with  common  ship  C2  (combat)  enterprise 
requirements  across  platforms. 

Inputs:  Historical  cost  data,  enterprise  architecture  and  requirements 

Tools:  Microsoft  Excel.  Visibility  and  Management  of  Operating  and  Support 

Costs  (VAMOSC)  database 
Outputs:  Cost  analysis 

SCHEDULE  &  DELIVERABLES 
Schedule 

The  schedule  developed  for  the  ER&A  project  is  shown  in  Figure  4.  The  period  of  performance 
is  defined  as  September  2(M)X  through  June  2009.  The  schedule  is  driven  by  the  milestones 
identified  below: 

•  Approval  of  PM  P 

•  Integrated  Product  Reviews  <#  I .  #2.  final  brief  out) 

•  Completion  of  the  Systems  Engineering  Design  Process  phases 


116 


Deliverables 

The  following  deliverables  have  been  identified  for  advisor  and  stakeholder  concurrence: 

•  November  2008:  PMP 

•  December  2008:  IPR  1  Presentation.  Report  Draft  Release  #1  which  will  focus  on: 

•  Program  Management  Plan 

•  Needs  Analysis  Overview 

•  Stakeholder  Analysis 

•  Mission  Thread  Definition 

•  Threat  .Assessment 

•  Risk  Management  Update 

•  The  Way  Forward 

•  March  2009:  IPR  2  Presentation.  Report  Draft  Release  #2  which  will  focus  on: 

•  Updates  from  IPR  #1 

•  Functional  Analysis  Overview 

•  Requirements  Definition 

•  Functional  Architecture  Status 

•  Value  System  Design 

•  Risk  Management  Update 

•  The  Way  Forward 

•  June  2009:  Final  Presentation:  Final  Report 

•  Updates  from  IPR  #2 

•  Final  Functional  Analysis 

•  Modeling  and  Simulation  Overview 

•  Modeling  and  Simulation  Results 

•  Cost  Analysis 

•  Risk  Management  Update 

Each  IPR  will  include  three  basic  sections.  A  progress  update  will  focus  on  the  work  and 
products  that  been  completed.  A  risk  management  update  will  focus  on  the  risks  identified  and 
mitigation  strategies  developed  for  medium  to  high  risks.  The  third  section  of  each  IPR  will 
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include  a  way  forward,  in  which  the  team  schedule  for  the  future  will  be  reviewed.  In  these  IPRs 


the  team  will  elicit  feedback  from  the  stakeholders  and  advisors.  Any  comments  provided  will 
be  addressed  prior  to  the  final  presentation. 
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PMP:  Appendix  A:  Acronym  List 


Acronym 

AV 

C2 

C4I 

CG 

COP 

CTP 

DCO 

DDG 

DoDCCRP 

DoDAF 

ER&A 

EFFBD 

FFG 

IPR 

in 

iws 

M&S 

MIO 

MSSE 

NPS 

NSWC 

OV 

PEO 

PMP 

POA&M 

SE 

SEDP 

SI 

suw 

TA 

VAMOSC 


Term 

All  View 

Command  and  Control 

Command.  Control.  Communications.  Computers.  Intelligence 

Guided  Missile  Cruiser 

Common  Operational  Picture 

Common  Tactical  Picture 

Defense  Connect  Online 

Guided  Missile  Destroyer 

Department  of  Defense  Command  and  Control  Research  Program 

Department  of  Defense  Architecture  Framework 

Enterprise  Requirements  and  Architecture 

Extended  Functional  Flow  Block  Diagram 

Guided  Missile  Frigate 

Integrated  Product  Review 

Integrated  Product  Team 

Integrated  Warfare  Systems 

Modeling  &  Simulation 

Maritime  Interception  Operations 

Masters  of  Science  in  Systems  Engineering 

Naval  Postgraduate  School 

Naval  Surface  Warfare  Center 

Operational  View 

Program  Executive  Office 

Project  Management  Plan 

Plan  of  Action  &  Milestones 

Systems  Engineering 

Systems  Engineering  Design  Process 

System  Integration 

Surface  Warfare 

Technical  Assistant 

Visibility  ami  Management  of  Operating  and  Support  Cost 
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APPENDIX  B:  STAKEHOLDER  INTERVIEW  QUESTIONS 


1.  What  arc  the  future  trends  in  Surface  Warfare  and  Maritime  Interdiction  Operations  that  will 
drive  ship  combat  system  requirements? 

a.  Technical 
c.g.  OA.  SOA 

b.  Operational 

c. g.  Distributed  operations 

2.  What  are  the  major  current  and  emerging  surface  threats  to  U.S.  Navy  platforms  that  the  ship 
combat  sy  stem  must  address? 

c.g.  Cyber  attacks,  piracy,  semi-submersible  or  other  low-observable  surface  vessels, 
FAC/swarm  attacks,  suicide  attack  by  unmarked  (civilian)  vessels 

3.  Limited  to  the  Surface  Warfare  and  Maritime  Interception  Operations,  what  major 
requirements  can  you  identify  for  the  ship’s  combat  system? 

a.  Relative  to  functionality  the  ship  combat  system  must  support? 

b.  Relative  to  the  performance  or  operational  availability  of  the  system? 

c.  Relative  to  specific  requirements  for  system  (ship  and  coalition)  redundancy''/ 

d.  Relative  to  the  current  &  future  interfaces  the  ship  combat  system  must  support? 

c.  Relative  to  the  operational  environment  that  the  ship  combat  system  must  operate  in? 

4.  What  arc  the  performance  and/or  RMA  criteria  that  define  the  “goodness”  of  the  ship  combat 
system? 

5.  What  performance  aspects  of  the  ship  combat  systems  are  most  important?  Which  arc  least 
important? 


6.  Are  there  any  constraints  on  the  combat  system  that  we  need  to  include  in  our  requirements 
analysis? 

7.  Are  there  any  cost  or  schedule  constraints  that  we  need  to  be  aware  of? 

c.g.  Weapon  system  must  be  ready  for  certain  test  events  X  months  prior  to  full  ship  test  events. 

8.  Mow  does  the  trend  toward  net-ccn tricity  &  reliance  upon  coordinated  tracks,  cooperative 
fires,  etc.  impact  combat  system  command  and  control  functionality  and  performance? 
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9.  Docs  the  trend  toward  nct-ccntric ity  &  reliance  upon  coordinated  tracks,  cooperative  tires, 
etc.  drive  navigation  accuracy  or  track  measurement  report  precision,  gridlock  precision,  track 
update  rates,  or  other  perfomtanee  metrics? 

10.  What  do  you  expect  as  the  final  product  of  this  effort?  Do  you  expect  a  section  of  a  formal 
requirements  document  or  a  product  that  would  be  expanded  by  a  follow-on  effort? 

11.  Do  you  have  any  additional  comments  or  recommendations?  Do  you  know  of  any  other 
stakeholders  we  could  speak  with  from  the  resource  sponsor  (OPNAV)  or  licet  (CFFC)? 
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APPENDIX  C:  C2  REQUIREMENTS.  VSD  &  ARC  HITECTURE  MATRIX 


In  Tabic  1 1  each  requirement  is  listed  in  the  "Requirements"  column  and  is  tracked  by 
number  in  a  hierarchical  arrangement  in  which  higher  level  requirements  arc  decomposed  into 
multiple  lower  level  requirements,  as  indicated  by  the  number  of  decimal  points  in  the  requirement 
number.  (Requirement  1.2  decomposed  into  1.2.1.  1.2.2.  etc.)  The  "Rationale”  column  contains 
the  source  information  for  that  requirement,  and  may  be  attributed  to  a  Joint  or  Navy  publication,  a 
stakeholder,  the  mission  threads,  or  another  doctrinal  source.  In  the  ease  where  the  rationale  refers 
to  an  NTA.  definition  can  be  found  in  the  Navy  Tactical  Task  List.  Requirements  that  do  not 
reference  an  external  source  were  derived  as  necessary'  to  'fill  in*  the  architecture  when  required. 
The  "Type"  column  indicates  whether  a  requirement  is  a  functional  or  performance  requirement, 
or  a  constraint.  Functional  requirements  describe  what  the  system  must  be  able  to  do. 
Performance  requirements  describe  how  well  the  system  must  perform.  Constraint  requirements 
describe  other  operational  or  design  limitations  with  which  the  system  must  comply.  The  "Value 
System  Design"  column  further  describes  the  requirement  in  terms  of  the  intended  objective  and 
Performance  Measures.  The  "Architecture  Function"  column  contains  the  architecture  function  to 
which  the  requirement  has  been  allocated.  Only  the  lowest  leaf  levels  in  the  requirements 
hierarchy  have  been  allocated  to  functions.  A  "leaf*  is  the  lowest  decomposition  of  a  requirement 
in  the  hierarchy.  The  leaf  level  requirements  and  associated  functions  support  the  higher  level,  or 
parent,  requirement. 
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Table  11:  Complete  C2  Requirements  and  VSD 

This  table  centum*  a  complete  listing  of  all  S>Mem  Requirements  and  the  Value  System  Design. 


I  Command  and  Control 

The  system  shall  support  Command 

and  Control  activities. _ 

I .  I  Conduct  Maritime  Interception 
The  C2  system  shall  support 
maritime  interception  operations. 


Functional 


Functional  Obj:  Assess  if  visit  and  boarding 
were  successful. 


NTA  1.4.6 


PERFORMANCE  MEASURE: 
Ability  of  C2  system  to  support 
visit  and  board  contact. 


Goal:  99%  of  all  MIC)  Missions 

conducted  successfully _ 

Obj:  Assess  if  boarding  party  and 
C2  can  successfully  inspect  and 
examine  a  vessel. 


1.1.1  Conduct  Visit 
The  C2  system  shall  provide  the 
capability  for  ship  personnel  to 
request  a  vessel  to  heave  to.  for 
purposes  of  conducting  a  visit. 


NTA  1.4.6. 1 


Functional 


PERFORMANCE  MEASURE 
Ability  of  C2  to  facilitate 
conducting  a  visit  on  a  vessel. 


Goal:  99%  of  all  MIC)  visits 
successful 
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1.1. l.l  Query 

The  system  shall  support  the 
query  ing  of  vessels  and  the 
transmissions  of  notifications  to 
conduct  VBSS  operations. 


1.1. 1.2  Request  to  Board 
The  C2  system  shall  provide  the 
capability  for  ship  personnel  to 
request  a  vessel  to  heave  to.  for 
purposes  of  conducting  a  visit. 


NTA  1.4.C 


1.1.2  Conduct  Search 

The  C2  system  shall  support  vessel 

searches. 


Functional 


.  I  Functional 


NTA  1. 4.6.2  Functional 


I 


3.4  Query  Ship 


Obj:  Assess  if  ship  personnel  can 
successfully  query  a  vessel. 

PERFORMANCE  MEASURE: 

Ability  of  C2  to  facilitate  query  of 
a  vessel. 

Goal:  99%  of  all  MIO  queries 
successful _ 

Obj:  Assess  if  the  request  to  board  3.5  Issue  Boarding  Order 
is  communicated. 

PERFORMANCE  MEASURE: 

Ability  of  C2  to  effectively 
communicate  a  request  to  board 
transmission. 

Goal:  99%  of  all  MIO 
transmissions  and  receipt  of  all 

boarding  message  are  successful. _ 

Obj:  Assess  if  C2  effectively  starts  3.5  Issue  Boarding  Order 
a  search  plan. 

PERFORMANCE  MEASURE: 

Ability  ofC2  system  to  find 
contact  and  evaluate  the 
compliance  of  the  vessel  under 
evaluation. 

Goal:  Probability  of  detection  of  a 
contact  during  sensor  scans  >  99% 


1.1.3  Conduct  Seizure 

The  C2  system  shall  support  the 
capability  to  identity  any  violation  of 
resolutions  or  sanctions. 

NT  A  1. 4.6.3 

1 . 1 .3. 1  Take  Possession  of  Vessel 
Upon  identification  of  a  resolution  or 
sanction  violation,  the  C2  system 
shall  support  the  action  of  taking 
legal  possession  of  the  vessel. 

NTA  1. 4.6.3 

1.1. 3.2  Take  Possession  of 
Contraband 

Upon  identification  of  a  resolution  or 
sanction  violation,  the  C2  system 
shall  support  the  action  of  taking 
legal  possession  of  the  contraband,  to 
include  goods  and  people. 

NTA  1. 4.6.3 

Functional 


Functional 


Functional 


i  1 

iT7HZ5?rair?rira 

Obj:  Assess  ifC2  system 
effectively  supporls  personnel  in 
seizure  of  a  vessel. 

PERFORMANCE  MEASURE: 
Capability  of  C2  system  to  identify 
vessels  in  violation  of  resolutions 
and'or  sanctions. 

Cioal:  Probability  of  correct  ID  of  a 
contact  >  99% 

Obj:  Assess  ifC2  correctly  IDs  that 
vessel  is  in  possession 

PERFORMANCE  MEASURE: 
Capability  of  C2  to  correctly 

Identify  vessels  in  possession 

Cioal:  Probability  of  correct  ID  of  a 
vessel  in  violation  >99% 

3.5  Issue  Boarding  Order 

Obj:  Assess  ifC2  correctly  IDs 
vessels  contents 

PERFORMANCE  MEASURE: 
Capability  of  C2  to  correctly 

Identify  a  vessel's  contents 

3.5  Issue  Boarding  Order 

Cioal:  Probability  of  correct  ID  of 
contents  of  a  suspected  vessel 
>99% 


Hi 


1.1.4  Maritime  Interception  USN.'USCG  Functional 

Operations  (M 10)  Reporting  2003 

The  C2  system  shall  support  the 

automated  reporting  of  query  and 

hoarding  status  and  Situation  Reports 

(SITREP). 


1 . 1 .4. 1  Maintain  Status  Stakeholder  Functional 

The  C2  system  shall  maintain  a  query  Analysis 
and  boarding  status  for  each  MIO 
action. 


1.1. 4.2  Provide  Repons  Stakeholder  Functional 

The  C2  system  shall  provide  surface  Analysis 
situation  reports. 


Obj:  Assess  ifC2  reports 
information  regarding  queries  and 
Warding  activity 

PERFORMANCE  MEASURE: 
Capability  of  C2  to  report  out 
information  regarding  MIO 
activities. 

Goal:  Probability  of  correctly 
reporting  of  query/boarding  status 
>99% 


Obj:  Asses  C2  functionality  in  3.4  Query  Ship 
maintaining  status  on  all  boarding  3.5  Issue  Boarding  Order 
and  query'  activities 


PERFORMANCE  MEASURE: 
Measure  C2  capability  in 
maintaining  a  database  of  all 
boarding  and  query  activities 

Goal:  C2  shall  keep  an  active  link 
on  status  of  boarding  party  >  99% 


Obj:  Assess  C2  ability  in  producing  4  Report  Status 
reports 


PERFORMANCE  MEASURE: 
Measure  C2  effectiveness  in 
producing  reports 

Goal:  Meantime  for  C2  to  provide 

to  CO  <  5  mins. 


1.1.5  Classify  and  Identify  Surface 
Contacts 

The  C2  system  shall  utilize  stored 
intelligence  data  to  classify  and 
identify  surface  contacts. 


2.3  Classify  Tracks 

2.4  Identify  Tracks 


USN/USCG 

2<)03 


Functional  Obj:  Determine  C2  classification 
completeness  and  accuracy 


PERFORMANCE  MEASURE: 
Ability  to  classify  as  friend,  foe, 
suspect,  or  assumed  friend  based 
on  database  information 


Goal:  Accuracy  and  completeness 

_ of  surface  contacts  >95% _ 

Functional  Obj:  Determine  C2  capability  of 
sensors  to  identify  an  object  under 
varied  noise,  weather,  terrain 
conditions 


1.2  Collect  Target  Information 
The  C2  system  shall  collect  target 
information  for  detecting,  identifying 
locating,  and  classifying  targets. 


NTA  2.2.1 


PERFORMANCE  MEASURE: 
Ability  of  sensors  to  identify  an 
object  under  varied  noise,  weather 
terrain  conditions 


Cioal:  Probability  of  detection  and 
classification  of  a  target  >99% 
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1 .2. 1  Receive  Sensor  Inputs 

The  C2  system  shall  utilize  radar, 
electro-optical  infrared  (EO.'IR), 
electronic  surveillance  (ES), 
identification  friend-or-foe  (IFF)  and 
automatic  identification  system  (AIS) 
data  in  the  classification  and 
identification  of  contacts. 

(ioddin, 

2008;  Haas  & 
Neel,  2008 

Functional 

1.2.1. 1  Sensor  Daia 

The  track  file  shall  include  radar, 
tO.  IR,  !£S.  acoustic,  IFF  and  AIS 
data. 

Functional 

1 .2. 1 .2  Correlate  Sensor  Data 

The  C2  system  shall  correlate  radar. 
EO.  IR,  ES,  acoustic.  IFF  and  AIS 
data  into  a  single  track  file. 

Functional 

1.2.2  Classify  Surface  Contacts 

The  C2  system  shall  classify  surface 
contacts. 

NTA  2.2. 1.3 

Functional 

Obj:  Assess  C2  functionality  in 
receiving  data  from  sensors  in 
detection,  ID,  and  classification  of 
contacts. 


PERFORMANCE  MEASURE: 
Ability  of  C2  to  correctly  and 
accurately  detect.  Identify,  classify 
contacts  from  sensor  data 


Goal:  Probability  of  correct 
detection,  II).  and  classification 
from  all  sensor  systems  >85% 


2.1  Store  and  Report 
Tracks 


2.5  Correlate.  Decorrelatc 
Tracks 

2.6  Associate 
Bearings.' Fixes  to  Tracks 


Obi:  Determine  C2  ability  to  assess 
contact  classification  completeness 
and  accuracy 


PERFORMANCE  MEASURE: 
Ability  of  C2  to  accurately  and 
completely  classify  all  contacts 


Cioal:  Probability  of  correct 
classification  and  accuracy  of 
surface  contacts  >99% 


1 .2.2. 1  Classification  Types 
Classification  types  shall  include: 
combatant, 

noncombatant  military'. 

merchant. 

fishing. 

pleasure. 


1. 2.2.2  Sensor  Inputs 
The  C2  system  shall  use  inputs  from 
organic  and  national  asset  sensors  to 
classify  contacts. 


1.2. 2. 3  Classification  Completeness  NT A 
The  C2  system  shall  assign  a  2.2.1 .3 .M  l 

classification  to  TBD  %  of  detected 

surface  contacts. 


Performance 


Obj:  Determine  if  C2  can 
appropriately  classify  vessels  by 
type  or  category'  (combatant,  non- 
combatant  military,  merchant, 
fishing,  etc). 

PERFORMANCE  MEASURE: 
Ability  of  C2  to  classify  by  type  of 
vessel 

Goal:  Probability  of  correct 
classification  of  vessel 
>99% 


Obj:  Assess  C2  functionality  in 
using  data  from  organic  and 
national  asset  sensors  to  classify 
contacts. 

PERFORMANCE  MEASURE: 
Ability  of  C2  to  effectively  use 
inputs  f  rom  organic  and  national 
asset  sensors  to  classify  contacts. 

Goal:  Probability  of  correct 
classification  based  on  asset 
sensors  >85% 


2.3  Classify  Tracks 


2.3  Classify  Tracks 


2.3  Classify  Tracks 


132 


1.2. 2.4  Classification  Accuracy 

The  C2  system  shall  assign  a  conect 
classification  to  TBD  %  of  classified 
surface  contacts. _ 

1. 2.2.5  Classification  Timeliness  |nTA 
The  C2  system  shall  correctly 
classify  TBD  %  of  detected  contacts 

within  TBD  minutes. _ 

1.2.3  Identify  Contacts 
The  C2  system  shall  identify  contacts 
as  friendly  or  hostile. 


Performance 


2.3  Classify  Tracks 


Performance 


2.3  Classify  Tracks 


JP  1-02,  NT  A  Functional 

2.2. 1.4 


Obj:  Determine  C2  ability  to  ID 
contacts 


PERFORMANCE  MEASURE 
Ability  of  C2  to  correctly  and 
accurately  ID  contacts 


Cioal:  Probability  of  correct  and 
accurate  ID  of  contacts  during 
active  scanning  >99% 


1.2.3. 1  Identification  Completeness  NTA 

The  C2  system  shall  assign  an  2.2.1 

identity  to  TBD  %  of  classified 

surface  contacts. _ 

1.2. 3. 2  Identification  Accuracy 
The  C2  system  shall  assign  the 
correct  identity  to  TBD  %  of 

identified  surface  contacts. _ 

1.2. 3. 3  Identification  Timeliness  NTA 

The  C2  system  shall  correctly  2.2.1 

identify  TBD  %  of  classified  contacts 

as  friendly  or  hostile  within  TBD 
minutes. 


Performance 


2.4  Identify  Tracks 


ifv  Tracks 


Performance 


Performance 


2.4  Identify  Tracks 
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1. 2. 3.4  Automated  Identification 
The  system  shall  use  range  ring, 
radar.  EO'IR,  ES.  acoustic,  IFF  and 
AIS  data  to  identify  targets. _ 

1. 2.3.4. 1  Kinematic  Information 
The  C2  system  shall  use  kinetic 
information  to  identity  targets. 

1.2.3.4.2  Muzzle  Flash 

The  C2  system  shall  use  muzzle 
Hashes  to  identity*  targets. 


Haas  &  Neel 
2008 


Functional  Same  as  sensor  requirements 
PMsGoals 


2.4  Identify  Tracks 


Haas  &  Neel 
2008 


Functional  Same  as  sensor  requirements 
PMsGoals 


2.4  Identify  Tracks 


Haas  &  Neel 
2008 


Functional  Same  as  sensor  requirements 
PMsGoals 


1 .2.4  Localize  Contacts 
The  G2  system  shall  localize  the 
position  of  surface  contacts. 


NT A  2.2. 1.5  Functional 


Obj:  Assess  if  C2  can  create  tracks 
from  multiple  sources  of  data  and 
communication  networks  of 
detected  contacts 


PERFORMANCE  MEASURE: 
Ability  of  C2  to  create  local  and 
composite  tracks  of  contacts 
detected 


Goal:  Probability  of  creating 
correct  and  accurate  tracks  of 

_ surface  contacts  >8S% _ 

Functional  Same  as  1.2.4  objectives  and 
performance  measures 


1 .2.4. 1  Track  &  Status  Reponing 
The  C2  system  shall  repon  track  data 
for  all  surface  contacts  and  own  ship 
status  data  via  Link- 16  and  GCCS-M 


2. 1  Store  and  Report 
Tracks 
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1 .2.4.2  Sensor  Netting  and 

Distributed  Weapons  Control 

The  C2  system  shall  be  able  to 
exchange  contact  data  with  other 
platforms  to  form  local  tracks. 

Haas  &  Neel 

2  (MIS 

Functional 

Same  as  1.2.4  objectives  and 
performance  measures 

1 .2.4.2. 1  Engagement 

The  C2  system  shall  be  able  to 
engage  targets  using  contact  data 
from  other  platforms. 

Haas  &  Neel 
2008 

Functional 

Obj:  Determine  C2  ability  to  issue 
engagement  orders  from  contact 
data. 

PERFORMANCE  MEASURE: 
Capability  of  C2  to  issue 
engagement  orders  from  contact 
data 

Cioal:  Mean  time  in  issuing 
engagement  order  <  30  seconds 

2.2  Form  Tracks 

1.2.4.2.2  Sensor  Netting 

The  C2  system  shall  be  able  to  send 

contact  reports  to.  and  receive  contact 

reports  from,  other  platforms,  using 

contact  data  from  other  platforms  to 

form  tracks  with  own  ship  contact 

reports. 


1.2.5  MIO  Intelligence 
The  C2  system  shall  utilize  available 
intelligence  data  to  classify  and 
identify  surface  contacts 


Obj:  Assess  C2  ability  to 
participate  in  a  scnsor.net  centric itv 
environment 

PERFORMANCE  MEASURE: 
Capability  of  C2  to  send  and 
receive  contact  reports. 

Capability  of  C2  to  use  contact  data 
from  other  platforms  to  form  tracks 
with  own  ship  contact  reports. 

Goals: 

Probability  of  successful 
transmission  and  receipt  of  contact 
reports  >  95% 

Probability  of  successful 
integration  of  other  platform 
contact  data  >  95% 


Obj:  Determine  C2  ability  in 
utilizing  available  database 
intelligence  to  classify  and  ID 
contacts 

PERFORMANCE  MEASURE: 
Ability  of  C2  to  correctly  and 
accurately  classify  and  ID  contacts 

Goal:  Probability  of  correct  and 
accurate  classification  and  ID 
>99% 


1.2.5. 1  Automatic  Identification 
System 

The  C2  system  shall  use  commercial 
vessel  intelligence  data  to  support  the 
classification  and  identification  of 
surface  contacts. 

USCC  2008 

Functional 

Same  as  1.2.5  objectives  and 
Performance  measures 

2.4  Identify  Tracks 

1. 2.5.2  National  Asset  Intelligence 
The  C2  system  shall  receive,  parse 
and  store  intelligence  data  from 
National  Intelligence  Assets, 
including  National  Maritime 
Intelligence  Center  (Merchant  Ship 
(Characteristics  &  Hidden 
Compartment  Book)  and  Seal  ink 
Database  of  Vessels  (ELINT 
parameters  of  known  vessels). 

USN/USCG 
2003:  MIO 

thread 

Functional 

Same  as  1 .2.5  objectives  and 
Performance  measures 

2.4  Identify  Tracks 

1.2.6  Link  Planning 

The  system  shall  be  able  to  receive, 
parse  and  apply  the  OPTASK  LINK 

derived 

Functional 

3.6.3  Develop  Track 
Management  Policy 
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1.3  Process  Targets 

The  C2  system  shall  process  surface 

targets  to  employ  response  systems. 


NTA  3. 1 


1.3.1  Pre-planned  Responses  (PPR) 
The  C2  system  shall  be  able  to 
receive,  parse  and  implement  PPRs. 

CNO  2007 

1.3.2  Request  Attack 

The  C2  system  shall  be  able  to  order 
an  attack  on  a  specific  target  or 
position. 

NTA  3.1.1 

1 .3.2.1  Request  Timeliness 

NTA 

The  C2  system  shall  submit  TBD% 
of  all  attack  requests  w  ithin  TBD 
minutes. 

3.1.1. M2 

Functional 


Dbj:  Assess  C2  capability  to 
correctly  and  accurately  ID/classify 
contacts  and  make  command  and 
decision  (C&D)  in  contact 
processing  and  action  to  contacts 

PERFORMANCE  MEASURE: 
Evaluate  C2  ability  to  process  ID 
and  classification  of  contacts  in 
making  C&D  actions. 

Goal:  Probability  of  correct  action 
based  on  ID  and  classification 
>99.9% 


Same  as  1.3  objectives  and 
Performance  measures 


3.6. 1  Develop 
Engagement  Guidance 


Functional  Same  as  1.3  objectives  and 
Performance  measures 


Performance  Obj:  To  submit  attack  requests  in  a  3.2.1  Estimate 

timely  manner.  Engagement  Effectiveness 

3.2.2  Identify  Engagement 
PERFORMANCE  MEASURE:  Conflicts 

Timeliness  of  attack  requests  3.2.3  Compile  Weapon 

I  argct  Pairing  Options 
Goal:  The  C2  system  shall  submit  3.3  Issue  Engagement 
TBD%  of  all  attack  requests  within  Order 
TBD  minutes. 


PERFORMANCE  MEASURE: 
Timeliness  of  attack  requests 


1.3.3  Select  Surface  Target  to  Attack 
The  C2  system  shall  select  the 
surface  target  to  attack. 

NTA  3.1.2 

Functional 

1 .3.3. 1  Define  Target  Selection 
Criteria 

The  C2  system  shall  allow  tor 
definition  of  target  selection  criteria 
for  attack. 

NTA  3.1.2 

Functional 

1. 3.3.2  Weapon  Intercept  Points 

The  C2  system  shall  determine 
weapon  intercept  points. 

NTA  3.1.2 

Functional 

1 .3.3.2. 1  Correlate  Target  Reports 

The  C2  system  shall  correlate  target 
reports  into  a  track  list  and  maintain 
the  target  list. 

NTA  3.1.2 

Functional 

1.3. 3.2.2  Update  Intercept  Points 

The  C2  system  shall  update  weapon 
intercept  points. 

NTA  3.1.2 

Functional 

1.3. 3. 2.3  Duplicate  Tracks 

The  C2  system  shall  avoid  duplicate 
track  tiles  for  single  objects. 

NTA  3.1.2 

Functional 

Same  as  1 .3  objectives  and 
Performance  measures 

Same  as  1.3  objectives  and 
Performance  measures 

3.1.1  Identify  Threats 

3.1.2  Prioritize  Threats 

3.2.1  Estimate 

Engagement  Effectiveness 

3.2.2  Identify  Engagement 
Conflicts 

3.2.3  Compile  Weapon 
Target  Pairing  Options 

Same  as  1.3  objectives  and 
Performance  measures 

Same  as  1.3  objectives  and 

Perto nuance  measures 

2.5  Correlate 'Dccorrclate 

Tracks 

Same  as  1 .3  objectives  and 
Performance  measures 

3.1.3  Identify  Actions 
Required  for  Each  Threat 

3.2.1  Estimate 

Engagement  Effectiveness 

3.2.2  Identify  Engagement 
Conflicts 

3.2.3  Compile  Weapon 
Target  Pairing  Options 

Same  as  1.3  objectives  and 
Performance  measures 


2.5  Correlate 'Dccorrclatc 
Tracks 


2.4  Identify  Tracks 

2.5  Correlate. Decorrclate 
Tracks 

2.6  Associate 
Bearings.1  Fixes  to  Tracks 

3.1.1  Identify  Threats 

3.1.2  Prioritize  Threats 

3.1.3  Identify  Actions 
Required  for  Fach  Threat 

3.1.1  Identify  Threats 

3. 1 .2  Prioritize  Threats 

3.1.3  Identify  Actions 
Required  for  Fach  Threat 

3.2.1  Estimate 
Engagement  Effectiveness 

3.2.2  Identify  Engagement 
Conflicts 

3.2.3  Compile  Weapon 


1 .3.3.3  Examine  Target 
The  C2  system  shall  examine  each 
target  to  determine  if  and  by  what 
time  to  issue  an  attack  order. 


NTA  3.1.2 


Functional  Same  as  1.3  objectives  and 
Performance  measures 


1. 3.3.3. 1  Target  Evaluation 
Percentage 

The  C2  system  shall  evaluate  TBD% 
of  all  targets  identified  for  attack. 

1.3. 3. 3. 2  Evaluation  Timeliness  NTA 
The  C2  system  shall  complete  target  3. 1 .2 
selection  within  TBD  minutes  allcr 

the  contact  has  been  localized  or 
identified  (whichever  is  greater). 


NTA 


Performance 


Performance 


1. 3.3.4  Maintain  Target  List 
The  C2  system  shall  maintain  the 


Functional  Same  as  1 .3  objectives  and 
Performance  measures 


2.7  Manage  Track 
Numbers 


NTA  3. 1 


Functional  Same  as  1.3  objectives  and 
Performance  measures 


2.5  Correlate.1  Decorrclate 
Tracks 

3. 1 .2  Prioritize  Threats 

3.1.3  Identify  Actions 
Required  for  Each  Threat 
3. 1 .3  Identify  Actions 
Required  for  Each  Threat 


l . i.i.i  l  rack  Data  c  omparison 
The  C2  system  shall  allow  for 
comparison  of  target  track  data  to 
selection  criteria. 


1. 3.3.6  Warning  Orders 

The  C2  system  shall  be  able  to  issue 

warning  orders  to  targets  selected  for 


NTA  3.1 


Functional  Same  as  1.3  objectives  and 
Performance  measures 


attack 
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1.3.4  Select  Platform(s)  and  NTA  3.1.3  Functional 

System(s)  for  Attack 

The  C2  system  shall  determine  best 

weapon  system,  based  on  availability. 

intercept  time,  intercept  point,  and 

probability  of  negation,  to  employ 

against  a  particular  target. 


1.3.4. 1  Process  Weapon  System  NTA  3.1.3  Functional 
Status 

The  C2  system  shall  process  status 
information  from  the  engaging 
weapon  system. 


Obj:  To  determine  capability  of  C2 
to  select  best  weapon  system  for 
target 

PERFORMANCE  MEASURE: 
Mean  time  for  selected  weapon 
system  to  engage  target. 

Accuracy  of  target  impact. 

Goals: 

Missile:  Time  <  5  minutes  , 
Accuracy  of  engagement  >  99 % 
Small  Boat:  Time  less  than  X 
minutes.  Accuracy  >  99% 

Ship:  Time  less  than  5  minutes. 
Accuracy  >99% 


Obj:  To  determine  capability  ofC2 
to  process  weapon  status 
information. 


T2.1  Estimate 
Engagement  Effectiveness 


PERFORMANCE  MEASURE: 

1 )  Probability  of  accurately 
determining  weapon  system 
availability  and  ready  status 

2)  Mean  time  to  determine  weapon 
system  availability  and  ready  status 


Goal: 

Accuracy  >  99% 

Mean  Time  <  5  minutes 


1. 3.4.2  Weapon-Target  Pairing 

The  C2  system  shall  assign  all  high 
priority  targets  to  at  least  one 
engagement  system. _ 

1.3.4. 3  Pairing  Timeliness 
The  C2  system  shall  complete 
weapon-target  pairing  within  TBD 
seconds  after  a  target  has  been 
assigned  for  attack. 


NT A 


NTA 
3. 1.3. M2 


1. 3.4.4  Engagement  Coordination 
The  system  shall  be  able  to  support 
coordination  of  engagements  with 
other  operational  nodes  and  friendly 
forces. 


Performance 


3.2.3  Compile  Weapon 
Target  Pairing  Options 


Performance 


3.2.1  Estimate 
Engagement  Effectiveness 

3.2.2  Identity  Engagement 
Conflicts 

3.2.3  Compile  Weapon 


Obj:  To  determine  capability  of  C2 


Functional 


1 .3  Display 

to  coordinate  weapon  engagements  |  Engagcmcnt'VBSS  Status 

1 .5  Display  Command 
Data 

3.2.1  Estimate 
Engagement  Effectiveness 

3.2.2  Identify  Engagement 
Conflicts 

3.2.3  Compile  Weapon 
Target  Palling  Options 

3.6.1  Develop 
Engagement  Guidance 

3.6.2  Develop  Sensor 
Plans 


PERFORMANCE  MEASURE 
Percent  of  surrounding  C2 
platforms  notified  of  weapon 
engagement  plans. 


Goal:  Notified  C2  of  pending, 
pnor.  and  future  engagements 
X% 


1. 3.4.5  Control  of  Non-Kinclic 

Effectors 

The  02  system  shall  be  able  to 
employ  non-klnctic  effectors, 
including  RF  weapons,  prop-fouling 
devices  and  ES  systems. 


Stockbaucr  Functional 
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1. 3.4.5. 1  Non-Kinctic  Weapons 
Assignment 

The  C2  system  shall  be  able  to 
estimate  the  effectiveness  of  non- 
kinctic  effectors  against  all  tracks  and 
present  all  kinctie  and  non-kinctic 
effect  or  options  to  the  operator. 


Functional 


i.3.4.5.2  Non-Kinetic  Weapons 
Control 

The  C2  system  shall  be  able  to 

control  non-kinctic  weapons. _ 

1. 3.4.6  Use  Rules  of  Engagement  NTA3.I 

The  C2  system  shall  allow  for  input 
of  rules  of  engagement  and  armed 
laws  of  conflict  and  their  use  in  the 
target  selection  for  attack  decision. 


Functional 


Functional 


Dbj:  To  determine  capability  ofC2 
lo  employ  non-kinctic  effectors. 

PERFORMANCE  MEASURE: 
Percent  of  non-kinetic  effectors 
available  for  use. 

(ioal:  Available  non-kinctic 
effectors  for  operational  use  >  99% 


Dbj:  To  determine  capability  ofC2 
to  select  best  non-kinctic  effect  or 
for  target 

PERFORMANCE  MEASURE: 
Mean  time  for  selected  non-kinctic 
effect  to  impact  target. 


3.2.1  Estimate 
Engagement  Effectiveness 

3.2.2  Identify  Engagement 
Conflicts 


Cioal:  Time  <  15  minutes 


Obj:  To  determine  the  capability  of  3.3  Issue  Engagement 
C'2  in  utilizing  non-kinctic  WCS.  Order 


Same  as  1.3  objectives  and 
Performance  measures 


3.1.1  Identify  Threats 

3.1.2  Prioritize  Threats 

3.1.3  Identify  Actions 
Required  for  Each  Threat 

3.3  Issue  Engagement 
Order 


Functional  Obj:  To  determine  capability  of  C2 
to  develop  ‘order  to  fire* 


1.3.5  Develop  Order  to  Fire 
The  C2  system  shall  send  a  weapon 
tire  order  instruction  to  the  selected 
platform  and  weapon  system  with 
target  track  parameters,  required 
intercept  parameters  and  weapon 


NT A  3.1.4 


PERFORMANCE  MEASURE 
Completeness  of  Firing  Order 
Instruction. 


Cioal:  Completeness  of  firing  order 
during  operation  >  99% 


Performance 


l  .3.5. 1  Fire  Order  Timeliness 
The  C2  system  shall  develop  and 
issue  an  order  to  fire  within  TBD 
seconds  after  the  completion  of 
weapon-target  pairing. _ 

1. 3.5.2  Correct  Fire  Orders  NTA 

The  C2  system  shall  correctly  prepare  3.1 .4. M2 
all  fire  orders. _ 

1.3. 5.3  Correct  Engagement  System  NTA 

The  C2  system  shall  issue  TBD%  of  3.1 4.2.M3 

tire  orders  to  the  correct  engagement 

system. 


NTA 
3.1 .4. Ml 


3.3  Issue  Engagement 
Order 


Performance 


3.3  Issue  Engagement 
Order 


Performance 


3.3  Issue  Engagement 
Order 
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NT  A  3.1.5 


1.3.6  Conduct  Tactical  Combat 
Assessment 

The  C2  system  shall  assess  the 
success  of  the  engagement. 


1.3.6. 1  Attack  Assessment 
Availability 

The  C2  system  shall  provide  combat 
assessment  for  TBD%  of  all  engaged 
targets. 


NTA 
3. 1.5. Ml 


Functional 


Obj:  To  determine  capability  ofC2 
to  complete  battle  damage 
assessment,  complete  munitions 
effect  assessment,  and  provide  re- 
attack  recommendations  (if 
accessary). 

PERFORMANCE  MEASURE: 
Accuracy  of  battle  damage 
assessment. 

Accuracy  of  munitions  effect 
assessment. 

Accuracy  of  Re-attack 
recommendations. 

Goal:  Battle  Damage  Assessment 
Accuracy  >  99% 

Munitions  Effect  Assessment 
Accuracy  >  99% 

Re-attack  recommendation 


accuracy 


>  991 


(i 


Performance 


J.7  Assess  Engagement 
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Performance 


1. 3.6.2  Attack  Assessment 
Timeliness 

The  C2  system  shall  complete 
assessment  of  attacks  within  TBD 
minutes. _ 

1. 3.6.3  COA  Assessment 

The  C2  system  shall  assess  the  couree 
of  action  upon  completion  of  the 

engagement _ 

1.4  Information  Exchange 
The  C2  system  shall  have  the 
capability  to  exchange  information 
with  shipboard  and  national  assets. 


NT  A 


3.7  Assess  Engagement 


Functional 


3.1.2  Prioritize  Threats 

3.1.3  Identify  Actions 
Required  for  Each  Threat 


NTA  5.1.1, 
SUW  &  MIO 
Threads 


Functional 


Obj:  Assess  C2  capability  in 
exchanging  information  with  allied 
participants 


PERFORMANCE  MEASURE 
Evaluate  C2  capability  in 
exchanging  data  to  necessary* 
participants 


Percent  of  shipboard  assets  with  the 
capability  to  exchange  information 
with  C2. 


Percent  of  national  assets  with  the 
capability  to  exchange  information 
with  C2. 


Cioal:  Shipboard  Communication  > 
99% 


National  Asset  Communication  > 
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1 .4. 1  Data  Format 

The  C2  System  data  format  shall  be 
compatible  with  TBD  information 
systems  as  defined  in  TBD  Interface 
requirements  documents. 

Functional 

Obj:  To  determine  if  C2  data  is 
compatible  with  TBD  information 
system. 

PERFORMANCE  MEASURE: 
Percent  of  data  format 
compatibility. 

Goal:  Data  Compatibility  among 
systems  >  X5% 

2. 1  Store  and  Report 

Tracks 

2.2  Form  Tracks 

3.1.1  Identify  Threats 

3.6  Develop  Kxecution 
Guidance 

4  Report  Status 
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1.4.2  Data  Exchange 
The  C2  system  shall  support 
obtaining,  relaying,  and  distributing 
data  and  information  with  sen1  ice, 
joint,  interagency,  intra-agency,  and 
coalition  forces. 


1 .4.2. 1  Data  Exchange  Information 
Information  shall  include  mission, 
courees  of  action,  tasking  orders, 
operational  plans  and  orders, 
intelligence,  environmental 
conditions,  friendly  unit  status  and 
location,  rclavine  I&W  information. 


Obj:  To  determine  capability  of  C2 
to  exchange  information  with 
services,  joint  interagency,  mtra- 
ugcncy,  and  coalition  forces. 

PERFORMANCE  MEASURE: 
Percent  of  data  successfully  relayed 
to  services,  joint  interagency,  mtra- 
agcncy,  and  coalition  forces. 


2.1  Store  and  Report 
Tracks 

2.2  Form  Tracks 
3.1.1  Identify  Threats 
3.6  Develop  Execution 
Guidance 

4  Report  Status 


Percent  of  data  successfully 
obtained  from  services,  joint 
interagency,  intra-agency,  and 
coalition  forces. 

Percent  of  data  successfully 
distributed  to  sen  ices,  joint 
interagency,  intra-agency,  and 
coalition  forces 

Goal:  Successful  relay  >  99% 

Successful  data  acquisition  >  99% 


Successful  data  distribution  >  99% 


Same  as  1.4  objectives  and 
Performance  measures 


1.2  Display  Track  Data 
l  .3  Display 

Engagement/VBSS  Status 

1 .4  Display  Sensor  Status 

1 .5  Display  Command 
Data 


1.4.3  Information  Types 
The  C2  system  shall  utilize  joint 
communication  links  to  distribute 
data  to  include  mission,  intelligence, 
status,  and  other  reports,  c.g.  courses 
of  action,  tasking  orden>,  operational 
plans  and  orders,  environmental 
conditions,  friendly  unit  status  and 
location.  I&W  information. 


Functional  Obj:  To  determine  capability  of  C2  2. 1  Store  and  Report 
to  distribute  data  via  joint  Tracks 

communication  links.  2.2  Form  Tracks 

3.1.1  Identify  Threats 

PERFORMANCE  MEASURE:  3.6  Develop  Execution 

Percent  of  joint  communication  Guidance 

links  usable  by  the  C2  system.  4  Report  Status 


NT  A  5.1.1 


Cioal:  Usability  of  Joint 

_ Communication  Links  >  85% 

Functional  Obj:  To  determine  capability  of  C2 
to  maintain  information  and  Naval 
Force  Status 


1.5  Maintain  Information  and  Naval 
Force  Status 

The  C2  system  shall  maintain  data 
and  information  for  decision  making 
and  maintaining  a  tactical  picture. 


NTA  5.1.3 


PERFORMANCE  MEASURE 
Percent  of  data  stored. 


Accuracy  of  Naval  Force  status 


Accuracy  of  Naval  Force  Status  > 
85% 


Performance 


1.5.1  Suitable  Display  Format 
Decisions  delayed  because  the  C2 
data  is  not  presented  to  the  decision 
maker  in  a  suitable  format  shall  not 
exceed  0.01%(threshold),  0.001% 
(objective) 


NTA 
5. 1.3. M3 
CPD  for 
CrCCS-M  v4 


l.l  Provide  Tactical 
Display  Configuration 
Options 

1.3  Display 

Engagement  VBSS  Status 

1.4  Display  Sensor  Status 

1.5  Display  Command 
Data 
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Performance 


1.5.2  System  Updates 

(U)  The  C2  system  track  file  and 
displays  shall  be  updated  within  20 
seconds  of  receiving  updated  data 

1.5.3  Maintain  and  Display  Tactical 
Picture 

The  C2  system  shall  maintain  and 
display  a  common  tactical  picture. 


NTA 


1 .2  Display  Track  Data 

2.2  Form  Tracks 


NTA  5. 1.3.1 


Functional 


Ob j:  Assess  C2  capability  to 
maintain  and  display  a  tactical 
picture. 


PERFORMANCE  MEASURE 
Evaluate  ('2  capability  in 
maintaining  a  common  tactical 
picture  with  all  participants. 


Cioal:  Meantime  in  C2  exchange  of 

messages  <  30  seconds _ 

Qbj:  Assess  C2  capability  in  1 .3  Display 

displaying  battle  space  picture  to  Engagement1  VB SS  Status 

operators  1 .4  Display  Sensor  Status 

1 .5  Display  Command 
PERFORMANCE  MEASURE:  Data 

Evaluate  C2  functionality  in 
displaying  information  on  the  battle 
space  to  operators 


1.5.3. 1  Tactical  Displays 
Operator  consoles  and  displays 
showing  tactical  picture  data  shall 
utilize  standard  symbology. 


Functional 


Cioal:  Meantime  in  C2  exchange  of 
messages  <  30  seconds 


Performance 


1. 5.3.2  Track  Ambiguity 
The  number  of  unresolved  track 
ambiguities  shall  not  exceed  TBD  per 
24  hour  period. 


NTA 


2.5  Corrclatc.'Dccorrclatc 
Tracks 
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1. 5.3.3  Dual  Tracks 

The  percentage  of  dual  tracks  shall 
never  exceed  TBD%  of  all  tracks 
displayed. 

NT  A 

5. 1.3.1. M2 

Performance 

1. 5.3.4  Track  Number  Consistency 
The  number  of  non-constant  track 
numbers  shall  not  exceed  TBD  per  24 
hour  period. 

NTA 

5. 1.3.1. M3 

Performance 

1. 5.3.5  Tactical  Picture 

The  C2  system  shall  meet  the 
following  performance  requirements. 

Stockbuucr 

2008 

Performance 

1 .5.3.5. 1  Ambiguous  Tracks 

The  C2  system  shall  hold  only  a 
single  track  for  each  surface  object 
for  at  least  TBD  percent  of  all  surface 
contacts. 

SIAP 

Performance 

1.5.3. 5.2  Continuity 

The  C2  system  shall  have  fewer  than 
TBD  track  number  changes  per 
surface  contact  during  tracks  life. 

SIAP 

Performance 

1.5.3. 5.3  Track  Consistency 

The  C2  system  shall  maintain  a 
consistent  track  number,  identity  and 
kinematic  data  with  Link-16  tracks 
for  TBD  percent  of  tracks. 

SIAP 

Performance 
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2.5  Corrclatc/Dccorrclalc 
Tracks 


2.5  Corrclalc'Dccorrclalc 
Tracks 


2.7  Manage  Track 
Numbers 


2.5  Correlate 'Dccorrclale 
Tracks 

2.7  Manage  Track 
Numbers 


NTA5.1.3.2  Functional 


1.5.4  Maintain  and  Display  Force 
Command  and  Coordination  Status 
Operator  consoles  and  tactical 
displays  shall  permit  display  of 
detailed  data  of  own-force  units, 
including  unit  ID,  task  organization 
and  mission  assignment. 


1.5.5  Maintain  and  Display  Unit  NTA  5. 1.3.3  Functional 
Readiness 

Operator  consoles  and  tactical 
displays  shall  permit  display  of 
detailed  data  of  own-force  units, 
including  unit  readiness,  mission 
capability,  weapon  status,  and  fuel 
state. 


Obj:  Assess  C2  capability  to 
maintain  and  display  a  tactical 
picture. 

PERFORMANCE  MEASURE: 
Evaluate  C2  capability  in 
maintaining  a  common  tactical 
picture  with  all  participants. 

Cioal:  Meantime  in  C2  exchange  of 
messages  <  30  seconds 

1 .5  Display  Command 

Data 

Obj:  Assess  C2  capability  to 
maintain  and  display  a  tactical 
picture. 

PERFORMANCE  MEASURE: 
Evaluate  C2  capability  in 
maintaining  a  common  tactical 
picture  with  all  participants. 

Cioal:  Meantime  in  C2  exchange  of 
messages  <  30  seconds 

1.4  Display  Sensor  Status 

Functional  Obj:  Determine  if  C2  effectively 
communicates  and  transfers  data 
and  situational  awareness  to 
participants  and  commanders 


1 .6  Analyze  and  Assess 
The  C2  system  shall  provide  the 
commander  with  tactical  situational 
awareness  data;  friendly  force  ID, 
task  organization,  task  assignment, 
and  readiness  data;  automated  access 
to  reference  threat  and  intelligence 
data,  decision  aids  and  optask 
reference  information  suitable  for 
effective  command  and  control  of 
assigned  units. 


NTA  5 


PERFORMANCE  MEASURE: 
Evaluate  C2  effectiveness  in 
communicated  and  displayed 
information  regarding  the  situation 
contacts,  assets,  and  threats  to 
participants  and  commanders. 


Cioal:  Meantime  in  C2  exchange  of 
messages  <  30  seconds 


1 .6. 1  Tailor-able  Display 

The  system  shall  provide  the  ability 
for  the  user  to  tailor  the  display. 

1.6.2  Situational  Awareness  TDAs 
The  C2  system  shall  display 
situational  awareness  information  to 
decision  maker*  using  tactical 
decision  aids  (TDAs). 


Functional 


1.1  Provide  Tactical 
Display  Configuration 

Options _ 

l  .3  Display 

EngagcmcntVBSS  Status 

1 .4  Display  Sensor  Status 

1.5  Display  Command 
Data 


Functional 


Obj:  Evaluate  C2  capability  in 
common  tactical 


maintaining 
picture  with  all  participants. 


PERFORMANCE  MEASURE 
Evaluate  C2  capability  in 

common  tactical 


maintaining 
picture  with  all  participants. 


Cioal:  Meantime  in  C2  exchange  of 
messages  <  30  seconds 
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1.6.3  Apply  Rules  of  Engagement 
(ROE) 

The  C2  system  shall  apply  rules  of 
engagement  (ROE)  to  all  developed 
plans  and  recommendations. 


NT  A  5.2. 1.3 
SUW  and 
MIO  threads 


Functional  Obj:  Assess  C2  capability  in 
effectively  applying  ROE 


3.6.1  Develop 
Engagement  Guidance 


PERFORMANCE  MEASURE 
Evaluated  C2  effectiveness  in 
applying  ROE. 


Goal:  Meantime  in  C2  exchange  of 
engagement  messages  <  30  seconds 
Obj:  Assess  C2  capability  in  COAs 
to  mission  needs. 


1 .6.4  Develop  Courses  of  Action 
(COA) 

The  C2  system  shall  develop  courses 
of  action  (COAs). 


NTA  5.3.3,  Functional 

SUW  &  MIO 

threads 


in  response 
environment,  and  contacts. 


PERFORMANCE  MEASURE: 
Evaluate  C2  response  to  mission 
needs,  environment,  and  contacts 
via  C2  COAs. 


Goal:  Meantime  for  C2  to  develop 
a  COA  <  5  mins. 


3.1.3  Identify  Actions 
Required  for  Each  Threat 


1 .6.4.1  COA  Recommendations  NTA 
The  C2  system  shall  recommend  a  5.3.3. M3 
minimum  of  TBD  COAs  per  tactical 
action. 


Performance 
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1. 6.4. 2  CO  A  Recommendation 
Ranking 

The  C2  TDAs  shall  permit  ranking  of 
COA  recommendations  in  order  of 
assessed  probability  of  success, 
confidence  level,  or  other  relevant 
performance  measure. 


Functional 


Obj:  Assess  C2  capability  in  COAs  3.2.3  Compile  Weapon 
in  response  to  mission  needs.  Target  Pairing  Options 

environment,  and  contacts. 


PERFORMANCE  MEASURE: 
Evaluate  C'2  response  to  mission 
needs,  environment,  and  contacts 
via  C2  COAs. 


Goal:  Meantime  for  C2  to  develop 

a  COA  <  5  mins. _ 

Obj:  Assess  C2  capability  in  COAs 
to  mission  needs. 


1. 6.4.3  COA  TDAs 
The  C2  system  shall  display 
recommended  COAs  to  decision 
makers  using  tactical  decision  aids 
(TDAs). 


Functional 


in  response 
environment,  and  contacts. 


PERFORMANCE  MEASURE: 
Evaluate  C2  response  to  mission 
needs,  environment,  and  contacts 
via  C2  COAs. 


Cioal:  Meantime  for  C2  to  develop 
a  COA  <  5  mins. 
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i 

1.7  Develop  Search  Plan 

The  C2  system  shall  develop  surface 
search  plans. 

SUW&  MIC) 
threads.  NT  A 
5.3.3 

Functional 

Obj:  Determine  C2  ability  to 
develop  a  search  plan  in  a  dynamic 
environment 

PERFORMANCE  MEASURE: 
Evaluate  the  ability  of  C2  to 
develop  search  plan  to  dynamic 
environments 

Cioal:  Meantime  for  C2  to  develop 
a  search  plan  <  5  mins. 

1.7.1  Types  of  Search  Plans 

The  C2  system  shall  be  capable  of 
developing  area  and  directed  search 
plans. 

NWP  3-20 

Functional 

Obj:  Determine  C2  ability  to 
develop  a  search  plan  in  a  dynamic 
environment 

PERFORMANCE  MEASURE: 
Evaluate  the  ability  of  C2  to 
develop  search  plan  to  dynamic 
environments 

Cioal:  Meantime  C2  takes  to  initiate 
a  search  plan  <  10  seconds 
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1 .7. 1 . 1  Search  Plan  Factors 
The  C2  system  shall  have  the 
capability  to  process  the  follow  ing 
information  when  developing  search 
plans: 

1 .  Prior  surveillance  (leverage 
COP/CTP  information) 

2.  Historical  operating  pattern 

3.  Platform  endurance  and  range 

4.  Weapons  and  sensor  capabilities 

5.  Size  of  the  area  and  threat  axis 

6.  Search  priorities 

7.  Environmental  factors 

8.  Shipping  density. _ 

1.7.2  Control  Sensors  SUW&MIO  Functional  Obj:  Determine  C2  capability  in 

The  C2  system  shall  be  able  to  direct  threads  directing  sensor  systems  in  an 

sensors  according  to  the  approved  approved  search  plan 

search  plan. 

PERFORMANCE  MEASURE: 
Evaluate  C2  ability  in  directing 
sensor  systems 


NWP  3-20 


Functional 


Obj:  Determine  C2  ability  to  3.6.2  Develop  Sensor 

develop  a  search  plan  in  a  dynamic  Plans 
environment 


PERFORMANCE  MEASURE: 
Evaluate  the  ability  of  C2  to 
develop  search  plan  to  dynamic 
environments 


Goal:  Meantime  C2  takes  to  initiate 
a  search  plan  <  X  seconds 


3.6.2  Develop  Sensor 
Plans 


Goal:  Meantime  C2  takes  in 
sending  a  message  to  direct  sensors 
<  10  seconds 


Performance 


1.7.3  Plan  Suitability  NTA 

1 00%  of  search  plans  developed  by  5 .3.3.M  1 
the  C2  system  shall  be  achievable. _ 

1.7.4  Plan  Timeliness  NTA 

The  C2  system  shall  develop  a  search  5.3.3.M2 
plan  within  30  minutes. 


3.6.2  Develop  Sensor 
Plans 


Performance 


3.6.2  Develop  Sensor 
Plans 
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1.7.5  Alternative  Plans 

The  ('2  system  shall  develop  TBD# 

of  alternative  search  plans. 


1.8  Constraint  Requirements 


1 .8. 1  Lifecycle  Impacts 

The  C2  system  shall  satisfy  the 

following  life  cycle  requirements. 


1.8.1. 1  CRUDES  Manning 
The  C2  system  shall  not  increase  the 
manning  requirements  on  any  Navy 
ships. 


NTA 
5 .3 .3  .M3 


Stockbaucr 

2008 


Stockbaucr 

2008 


1.8. 1.2  Training  Costs 

Stockbaucr 

The  C2  system  shall  not  increase  the 
cost  to  train  the  operators  of  the  C2 
system. 

2008 

1.8. 1.3  Support  Costs 

Stockbaucr 

The  C2  system  shall  not  increase  the 

2008 

cost  to  support  the  C2  system  post¬ 
installation. 

1.8. 1.4  Operational  Availability 

The  C2  system  shall  have  an 
operational  availability  of  at  least 
TBD%. 

Goddin  2(M)8 

1.8. 1.4. 1  MTBF 

T  he  C2  system  shall  have  a  Mean 
Time  Between  Critical  Failures  of 
atcr  than  TBD  hours. 


1 .8. 1 .4.2  Mean  Down  Time 
The  C2  system  shall  have  a  Mean 
Down  Time  of  less  than  TBD  hours. 


1.8.2  MOSA  Design 
The  C2  system  shall  implement  a 
MOSA  design,  while  maintaining  the 
independence  of  the  application  from 
the  underlying  computing  plant. 


1.8.3  DISR  Technical  Standards 
The  C2  system  shall  only  implement 
standards  found  in  the  Defense 
Information  Systems  Repository 
I  DISR). 


1.8.4  Net-Ready  KPPs 
The  C2  system  shall  be  compliant 
with  the  Net-Ready  Key  Performance 
Parameter  as  listed  in  the  table  below. 


1.8.5  Cost  KPP 

The  C2  system  cost  shall  not  exceed 
STBD. 


Constraint 


USD 

(AT&L). 

’The  Defense 

Acquisition 

System", 

2003; 

Stockbaucr 

2008 


Stockbaucr 

2008 


Constraint 


Constraint 


Constraint 


CJCS1 
6212.01  E 


Constraint 


Constraint 


I 


The  C2  system  shall  have  a  Mean 
Time  Between  Critical  Failures  of 
greater  than  TBD  hours. 

The  C2  system  shall  have  a  Mean 
Down  Time  of  less  than  TBD 
hours. 

The  C2  system  shall  implement  a 
MOSA  design,  while  maintaining 
the  independence  of  the  application 
from  the  underlying  computing 
plant. 

The  C2  system  shall  only 
implement  standards  found  in  the 
Defense  Information  Systems 
Repository  (DISR). 

The  C2  system  shall  be  compliant 
with  the  Net-Ready  Key 

Performance  Parameter  as  listed  in 

the  table  below. 

The  C2  system  cost  shall  not 
exceed  STBD. 
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APPENDIX  D:  ADDITIONAL  CORESIM  MODEL  VIEWS 


Figures  38-41  arc  the  Enhanced  Functional  Flow  Block  Diagrams  (EFFBD)  for  the  C2 
Architecture  Operational  Activities.  The  first  diagram  is  the  same  as  Figure  28  in  the  body  of  the 
report.  It  represents  the  top-level  view.  The  next  three  diagrams  represent  the  second  tier  of  the 
operational  activities,  including  Figure  29  from  the  body  of  the  report. 


Figure  38:  EFFBI)  of  Top-Level  C2  Operational  Activities 


This  EFFBD  discpiiys  lb:  top-level  operational  activities.  all  executed  in  parallel,  with  iteration  to 
support  multiple  successive  targets 
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Figure  39:  Collect  Target  Information  C2  Operational  Activities 

Thu  EFFBD  is  the  decomposition  of  the  "Collect  Target  Information"  Operational  Activity. 
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Figure  40:  Target  Processing  Cl  Operational  Activities 


This  EFFBD  is  the  decomposition  of  the  "Process  Targets"  Operational  Activity.  The  top  branch 
includes  activ  ities  associated  with  the  SUW  mission.  Tlic  bottom  branch  shows  the  activity 
associated  with  the  MIO 
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Figure  41:  Maintain  Information  and  Naval  Force  Status  C2  Operational 
Activities 

This  EFFBD  displays  lb:  "Maintain  Information  ami  Naval  Force  Status"  C2  Operational 
Activities. 

Figures  42-45  arc  the  Enhanced  Functional  Flow  Block  Diagrams  (EFFBD)  for  the  C2 
Architecture  System  Functions.  The  first  diagram  is  the  same  as  Figure  31  in  the  body  of  the 
report.  It  represents  the  top-level  view.  The  next  three  diagrams  represent  the  second  tier  of  the 
system  functions,  including  Figure  32  from  the  body  of  the  report. 
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Figure  42:  EFFBD  of  Top-Level  C2  System  Functions 


Thu  figure  sbems  the  top-level  system  functions  as  an  EFFBD,  where  c>:h  function  is  executed  in 
parallel  to  support  multiple  targets. 
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This  EFFBD  displays  !bc  sub-functions  of  the  "Display  Tactical  Data**  system  function 
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Figure  44:  Perform  Track  Management  C2  Functions 

This  EFFBD  displivs  Ibc  sub-functions  tlut  c(xii(xisc  tbc  “Perform  Track  Managcirnnf*  system 
function. 
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Figure  45:  Conduct  Combat  Control  C2  Functions 


This  figure  shows  the  child  functions*  of  the  Conduct  Combat  Control  function.  The  sefxiiutc 
brandies  show  the  functions  associated  with  the  SUNV  and  MIO  missions. 


APPENDIX  E:  ACRONYM  LIST 


Acronym  Term 


A1S  Automatic  Identification  System 


ASCM  Anti-Ship  Cruise  Missil 


Command  and  Control 


Command,  Control  and  Communication: 


C4I  Command,  Control.  Communications,  Computers.  Intelligence 


CBN  Chemical,  Biological  and  Nuclear 


CG  Guided  Missile  Cruiser 


COC  Combat  Operations  Center 


COP  Common  Operational  Picture 


COTS  Commcrcial-Off-Thc-Shclf 


CPN  Colored  Petri  Net 


CSCS  Center  for  Surface  Combat  Systems 


CSG  Carrier  Strike  (iroup 


Common  Tactical  Picture 


DAS  Defense  Acquisition  System 


DCO  Defense  Connect  Onlin 


DDCi  Guided  Missile  Destroyer 


Department  of  Defense  Information  Technology  Standards 
DISR  Repository 


DoDAF  Department  of  Defense  Architecture  Framework 


DOORS  Dynamic  Object  Oriented  Requirements  System 


DWC  Distributed  Weapons  Coordination 


EO/1R  Electro-Optical' Infra-Red 


FOR  Engage  on  Remote 


ER&A  Enterprise  Requirements  and  Architcctur 


EFFBD  Extended  Functional  Flow  Block  Diagram 


Electronic  Support 


EW  Electronic  Warfare 


FAC  Fast  Attack  Craft 


FFG  Guided  Missile  Frigate 


FI  AC  Fast  Inshore  Attack  Craft 


CiPS  IS  Global  Positioning  System  Interface  Specification 


l&W  Indications  &  Warning 


ICOMS  Inputs.  Controls.  Outputs,  ami  Mechanism 


IDEFD  Integration  Definition  language  0 


I  ED  Improvised  Explosive  Device* 


IFF  Identification  Friend  or  Foe 


I  PR  Integrated  Product  Review 


I PT  Integrated  Product  T cam 


ISR  Intelligence.  Surveillance  and  Rcconnaissanc 


I WS  Integrated  Warfare  System: 


JIC 


JFC 


LNG 


MBSH 


MIC 


Ml' 


MMSI 


MOSA 


MSSE 


MT 


NOC 


NPS 


Joinl 


Joint  Integrating  Cone 


Joint  Functional 


Liquid  Natural  Gas 


Model-Based 


Maritime 


Commander 


Mantime  Mobile  Serv  ice  Identi 


Modular  Open  Systems  Architecture 


Masters  of  Science  in 


Mes 


Naval 


School 


1TTC 


NSWM 


NTA 


NTTL 


NTTP 


NWP 


ONI 


Navy  Surface  Warfare  Manual 


Tactical  Task 


Tactical  Task  List 


Naval  Tactics,  Techniques  and  Procedures 


Naval  Warfare  Publication 


Office  of  Naval  Intclli 


OTH 


OV 


PEO 


PLAN 


PMP 


POA&M 


PPBE 


PPR 


RCS 


RF 


ROE 


ROV 


RP<i 


L 


SAM 


SCC 


E 


SEDP 


SIAP 


sn  REP 


SSDS 


Ovcr-thc-Horizon 


nal  View 


Executive  Office 


Ic's  Liberation  Aimy  Na 


ent  Plan 


Plan  of  Action  &  Milestones 


Execution  System 


lanned 


Radar  Cross  Section 


Fre 


Rules  of  Engagement 


Remotely  Operated  Vehicle 


Rocket  Propelled  Grenade 


Action 


Surfacc-to-Air  Missile 


Connected  Components 


Single  Intc 


Situation 


Design  Process 


Air  Picture 


Self-Defense  S 
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M 


suw 


suwc 


sv 


TA 


TBD 


TEU 


IIP 


TV 


UAV 


USV 


UNTL 


VAMOSC 


VBSS 


VHF 


VSD 


VVMD 


"i.riJTiTggt 


BTOl'VJI.S.HUi 


Surface  Warfare 


Surface  Warfare  Commander 


Standard  View 


cal  Assistant 


To  Be  Determined 


foot  l* qui valent  Units 


Tactics,  Tc 


Technical  View 


Unmanned  Aerial  Vehicle 


Unmanned  Surface  Vehicle 


Universal  Naval  Task  List 


Visibility  and  Management  of 


Visit  Board.  Search  and  Seizure 


of  Mass  Destruction 


and  Suooort  Cost 


Value 


W 
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